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SUMMARY 
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Due  to  the  advances  in  the  integrated  circuit  (TC)  technology,  more  and 
more  components  are  being  fabricated  into  a  tiny  IC  chip.  Since  the  number 
of  pins  on  each  chip  is  limited  by  the  physical  size  of  the  chip,  the  problem 
of  testing  becomes  more  difficult  than  ever,  especially  in  the  VLSI  (Very  Large 
Scale  Integration)  chips.  This  problem  is  aggravated  by  the  fact  that,  in 
nearlv  all  cases,  integrated  circuit  manufac turers  are  not  willing  to  release 
the  detailed  circuit  diagram  of  the  TC  chip  to  the  users.  Yet,  as  users  of 
the  1C  chips,  to  make  sure  that  the  implemented  system  is  reliable,  we  need 
to  test  the  IC  chips  and  the  systems  made  of  the  interconnection  of  these 
chips.  The  purpose  of  this  project  is  to  find  efficient  algorithms  for 
testing  LSI/VLSI  chips  and  LSI/VLSI-based  systems. 

As  a  result  of  the  rapidly  increasing  complexity  of  modern  digital  LSI/VLSI 
systems,  functional  testing  is  attracting  more  attention  than  ever  not  only  in  the 
computer  manufacturing  industry  but  also  in  the  diversified  potential  applications. 

Functional  testing  uses  a  representation  of  a  digital  system  higher  than 
the  gate-level  testing.  In  functional  testing,  functional  faults  with  respect 
to  the  functional  specification  (e.g.,  addition  operation  in  a  processor)  are 
tested  instead  of  a  signal  faults  (e.g.,  a  line  stuck-at  logical  0)  in  the 
circuit  representation.  The  purpose  of  functional  testing  is  to  validate  correct 
functional  operations  of  digital  systems  according  to  their  specifications.  — - 
Using  functional  testing  techniques,  one  cannot  only  reduce  the  test  generation 
complexity  but  also  obtain  a  test  set  for  testing  the  digital  systems  with  the 
same  functions  but  different  circuit  design/implementation  (e.g.,  parallel  adder 
vs.  serial  adder). 

U.-inx  RT1.  the  behavior  of  a  microprocessor  is  comprehensive! v  described, 
ar.d  functional  faults  derived  from  them  can  be  studied.  In  [1],  two  approaches 
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for  functional  testing  are  given  based  on  the  RTL  description.  The  first 
approach  constructs  a  data  graph  from  the  RTL  description  and  uses  the 
existing  algorithm  such  as  the  D-algorithm  or  path  sensitizing  method  to  generate 


the  tests  for  functional  faults.  In  the  second  approach,  the  symbolic  simu¬ 
lations  technique  is  used  to  generate  tests  for  detecting  faults  in  the  control 


signals.  In  [2],  a  formal  definition  of  KTL  is  defined  as 


k  "  (t , c)  Rj  +-  f  ( Rg^»  Eg 2’  *  *  • »  ^sv)  »  n 


where, 


Accec.:\'i  r ... 


C:<huI 
OTIC  7  Ac' 

Ui.ar^-Giict  J 


Availability  Codes 

I  Avail  and/or 
I  Special 


k  is  the  statement  label 

t  is  the  timing  and  c  is  the  condition  to  execute  the  statement  „  , 

By .  t 

Rj  is  the  destination  register  Dist. ibjtion/ 

Rg,.  is  the  ith  source  register  _ Av ability  C 

Dist  ^Vd:l  a:1^i 

f  is  an  operation  on  R  .  s  Special 

Si  | 

*-  represents  data  transfer 

->■  n  represents  a  jump  to  statement  n 

F or  example,  the  following  RTL  statement  No.  17:  (T,.  Cg)  R2',~R3+15  f*  ^8  means 

that  when  T<.  =  =  1,  the  sum  of  and  F^.  will  be  stored  in  R^  and  then  the 

program  jumps  to  statement  No.  38. 

Based  on  the  above  notation,  eight  catagories  of  fault  can  then  be  identified 
as  timing  faults  (t/t’),  condition  faults  (c/c’),  register  decoding  faults 
(R^/Rp,  instruction  decoding  (function  selection)  faults  (f/f),  control 
faults  (n/n’),  data  storage  faults  ((Rp/fR!)),  data  transfer  faults  (-'-/-*) 
and  data  manipulation  (function  execution  )  faults  ((f)/(f’)).  This  set  is 
functional  comprehensive  because  the  behavior  of  a  CPU  can  be  described 


by  a  sequence  of  RTL  statement.  Three  procedures  for  testing  those  five 
fault  catagories  (except  timing,  condition,  and  control  faults)  are  derived. 


v 

'  ‘  FD 


The  testing  requires  the  creation  of  executable  sequences  to  form  a  "sensitizing" 


path  which  leads  from  a  faulty  statement  to  a  statement  producing  faulty  output 
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information.  The  RTL  technique  seems  to  be  a  promising  approach  for  functional 
testing. 

Recently,  we  presented  three  algorithms  to  test  the  instruction  decoding 
function  of  microprocessors  [3].  The  algorithms  are  based  on  the  knowledge  of 
some  timing  and  control  information  available  to  users  through  microprocessor 
manuals  and  data  sheets.  The  tests  are  functional  in  nature.  We  establish  the 
order  of  complexity  of  the  algorithms  presented  in  this  paper.  As  an  example,  the 
test  complexity  for  a  microprocessor  is  computed  and  the  results  are  compared 
with  a  known  algorithm. 

In  f4]  wfe  present  the  state-of-the-art  for  the  functional  testing  of  LSI/ 

VLSI  devices  with  special  emphasis  on  microprocessor  testing.  Various  types 
of  IC  chips  are  briefly  discussed.  Different  approaches  for  testing  the 
functional  faults  of  LSI/VLSI  are  surveyed  and  the  comparison  of  these  methods 
are  given.  Fault  models  for  representing  the  faults  and  fault  coverage  of  the 
tests  are  discussed.  Some  of  the  important  unsolved  problems  and  current  trends 
in  testing  VLSI  are  pointed  out. 

A  new  approach  for  testing  VLSI  circuits  is  presented  in  [3].  Through 
backward  critical  path  tracing,  a  test  and  all  faults  detectable  by  the  test 
are  generated  simultaneously.  Therefore,  the  expensive  fault  simulation  is 
completely  eliminated.  We  present  a  critical  path  test  generation  procedure  for 
dicital  systems  described  by  hardware  description  language  (HDL) .  A  multiplication 
circuit  described  by  a  HDL  is  utilized  for  demonstrating  the  test  generation  method. 

In  this  report,  two  functional  testing  techniques  are  presented  with  in- 
depth  technical  discussion.  The  first  technique  (Part  1)  provides  a  functional 
testing  method  for  microprocessors.  Major  issues  in  testing  microprocessors  are 
clarified  and  defined.  The  second  technique  (Part  II)  is  a  new  algorithm  to 
systematically  perform  functional  test  generation  for  digital  LSI/VLSI  systems 
using  machine  symbolic  execution  technique.  Skills  and  concepts  developed  in  the 
area  of  artificial  intelligence  (AI)  are  applied. 
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The  first  technique  (Part  I)  is  for  testing  microprocessors  [6].  Among  the 
variety  of  LSI/VLSI  devices,  microprocessors  have  the  most  widespread  use  and  the 
highest  functional  complexity.  Therefore,  recently,  testing  microprocessors  has 
received  a  great  deal  of  attention.  Several  deterministic  testing  methods  have 
been  proposed.  The  more  important  approach  to  the  functional  testing  of  micro¬ 
processors  is  the  Thatte  and  Abraham's  method  which  has  been  widely  cited  in 
subsequent  literature,  but  their  fault  model  for  the  instruction  execution 

needs  to  be  generalized.  For  example,  in  an  instruction  decoding  fault  I./l.+l  , 

1  d  k 

it  is  assumed  that  instead  of  execution  I.,  both  instructions  I.  and  I,  are 

J  1  k 

executed  to  completion.  This  is  not  general.  In  order  to  make  the  fault  model 
more  general  and  practical,  partial  execution  of  an  instruction  under  fault  should 
be  considered.  In  addition,  a  microprocessor  is  a  type  of  complex  sequential 
machine.  The  current  approach  is  to  test  microprocessors  by  instruction  execution. 
Generally,  before  executing  an  instruction-under-test,  we  have  to  write  certain 
data  into  some  registers,  and  after  extending  the  instruction,  read  the  contents 
of  the  registers.  Therefore,  if  the  write  or  the  read  instruction  is  faulty, 
we  may  not  be  able  to  test  the  instruct  ion-under-test .  To  solve  this  problem, 
Thatte  and  Abraham  have  to  label  instructions  and  define  test  order  in  detail 
before  testing.  This  makes  the  test  procedure  more  complex. 

In  our  work,  we  first  establish  a  fault  model  for  microprocessors, 
emphasizing  the  control  fault  model  defined  at  the  register  transfer  language  (RTL) 
level,  since  it  is  convenient  to  represent  the  instruction  decoding  faults  and 
other  control  faults  at  such  a  level.  Then  we  consider  the  basic  instructions 
for  the  write  and  read  register  functions  as  the  kernel  of  microprocessor.  This 
kernel  can  be  represented  by  a  sequential  machine.  Based  on  the  fault  model,  we 
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can  use  checking  experiment  to  verify  the  kernel.  Thus,  testing  microprocessor 
is  divided  into  tow  steps,  i.e.  guarantee  the  correctness  of  the  kernel  first, 
then  use  the  kernel  for  testing  each  instruction.  Therefore,  the  complexity  of 
test  generation  will  be  reduced. 

The  second  technique  (Part  II)  is  based  on  two  major  foundations  [7]. 

First,  after  the  standard  syntax  of  a  register  transfer  language  is  defined,  a 
register  transfer  level  fault  model  is  developed.  All  types  of  faults  covered 
by  the  fault  model  were  analyzed  and  the  number  of  faultr  war  reduced. 

Secondly,  based  on  the  RT-level  fault  model  derived,  the  technique  of  symbolic 
execution  was  employed.  Symbolic  execution  is  a  kind  of  program  execution 
technique  which  manipulates  symbolic  variables  instead  of  variable  values  during 
program  execution.  In  A.T.,  this  technique  is  intensively  used  for  automatic 
theorem  proving,  program  verification,  programming  in  logic  and  many  other 
interesting  topics.  Since  test  generation  of  LSI/VLSI  systems  is  also  one  of 
the  important  issues  in  A. I.  applications,  the  symbolic  execution  technique  which 
is  popular  in  A. I.  application  was  adopted.  This  powerful  technique  seems  to 
provide  a  promising  solution  for  future  testing  problems  of  digital  LSI/VLSI 
systems . 
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PART  I 


I.  INTRODUCTION 


The  development  of  integrated  circuit  technology  has  resulted  in  a  vide 

range  of  applications  for  microprocessors.  Testing  of  microprocessors  is  a 

difficult  problem  because  of  the  complexities  cf  microprocessors.  The  problem 

is  more  serious  for  users  due  to  lack  of  information  on  internal  implementation 

of  microprocessors  and  other  VLSI  chips.  Recently,  several  deterministic  testing 

methods  have  been  proposed  to  solve  this  problem.  These  testing  techniques 

are  essentially  based  on  functional  level  [1-11], 

A  microprocessor  is  a  type  of  complex  sequential  machine.  The  current 

approach  is  to  test  microprocessors  by  instruction  execution.  Generally, 

before  executing  an  instruction-under-test  ve  have  to  write  certain  data 

into  some  registers,  and  after  executing  the  instruction,  read  the  contents 

of  the  registers.  Therefore,  if  the  write  or  the  read  instruction  is  faulty, 

we  may  not  be  able  to  test  the  Instruction-under-test.  To  solve  this  problem, 

Thatte  and  Abraham  [3]  have  to  label  instructions  and  define  test  order  In 

detail  before  testing.  However,  they  do  not  consider  the  partial  execution 

of  an  instruction.  So  for  instruction  decoding  fault  I. /I.  +  I  ,  it  is  assumed 

3  3  k 

that  instead  of  executing  I.,  both  instructions  I.  and  I,  are  executed  to 

j  J  k 

completion.  It  is  more  general  and  practical  to  consider  partial  execution  of 
an  instruction  under  fault.  Our  fault  model  allows  this. 

Ahraham  and  Parker  [5]  proposed  a  simplified  fault  model.  First,  one 
tests  all  internal  registers,  then  executes  all  instruction  and  data  manipulation 
functions. 


In  this  paper,  we  consider  the  basic  instructions  for  the  write  and  read 


register  functions  as  the  kernel  of  a  microprocessor.  This  kernel  can  be  represented 
by  a  sequential  machine.  Based  on  the  fault  model,  we  use  checking  experiment 
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to  verify  the  kernel.  Then  we  use  the  kernel  for  testing  each  instruction. 

The  control  fault  model  is  established  at  the  Register  Transfer  Language  (RTL) 
level,  since  it  is  convenient  to  represent  the  instruction  decoding  faults  and 
other  control  faults  at  such  a  level. 

Section  II  presents  a  fault  model  for  microprocessors,  emphasising  the 
control  fault  model  defined  at  the  RTL  level  instead  of  the  instruction  level. 
In  Section  III,  after  examining  roost  existing  off-the-shelf  microprocessors, 
we  derive  testing  requirements  based  on  different  types  of  operations.  In 
Section  IV,  we  define  the  write  and  read  sequences  as  the  kernel  of  a  micro¬ 
processor.  Then  Section  V  proposes  a  kind  of  test  data  which  is  quite  powerful. 
Section  VI  presents  the  verification  of  the  write  and  read  sequences.  Section 
VII  discusses  the  testing  of  control  faults.  Finally,  conclusions  are  given 


in  Section  VIII. 


II.  FAULT  MODEL 


The  functions  of  a  microprocessor  are  mainly  performed  by  instruction 
execution.  The  sequence  of  operations  for  an  instruction  can  be  described 
by  RTL.  Vie  consider  that  an  instruction  consists  of  a  series  of  RTL 
statements.  The  typical  statement  is  defined  as 
(conditions):  D-*-f  (S^,  ...»  S^»  •••) 

where 

D  -  destination 


-  Source 

f S2’  Si’  •••)  “  operation 

Destinations  and  sources  nay  be  internal  registers  of  a  microprocessor 
or  external  to  the  microprocessor  (i.e.  ,  data  bus,  address  bus,  etc.).  Ve  are 
only  concerned  with  those  internal  registers  which  are  of  interest  to  users,  so 
we  do  not  consider  implied  registers  6uch  as  buffers.  For  example,  data  transfer 


from  memory  to  memory'  can  be  described  as  DB^*DP^,  instead  of  Buffer'-DB^  followed 
by  DE^Buf  fer ,  where  DB  denotes  the  data  bus  which  represents  data  input  or  output 
of  memory,  i,j  denote  different  bus  cycles,  DB^  (read  from  memory)  is  ahead  of 
DB^  (write  into  memory). 

After  examining  most  existing  off-the-shelf  microprocessors,  e.g.  Intel  8080 
and  8086,  Zilog  80  and  8000,  Motorola  6800  and  68000,  the  RTL-like  operations 
car  be  divided  into  two  classes,  transfer  operations  (class  T,  TV-S),  and 
arithmetic  and  logical  operations  (class  A).  Class  A  car.  be  subdivided  into 


six  subclasses  based  on  the  combination  of  destitutions  and  sources  as  shown  in 


Table  1,  where  the  content  of  flag  bits  constitute  a  status  register. 


I 


Class 

Type  of  Expression 

Operation 

A1 

D*f (D) 

BIT  SET  i 

BIT  RESET 

BIT  COMPLEMENT 

INCREMENT 

DECREMENT 

DECIMAL  ADJUST 

SHIFT 

ROTATE 

COMPLEMENT 

NEGATE 

CLEAR 

A  2 

EM-f  (D,S) 

ADDITION 

ADDITION  WITH  CARRY 

SUBTRACTION 

SUBTRACTION  WITH  BORROW 

AND 

OR 

XOR 

IKf(S) 

- - - — - — 1 

EXTENT)  SIGN 

A3 

i>f (s1,s2) 

ADDITION,  P-*-Sj+S,, 

D^f (D,S1>S2) 

ADDITION,  IMH-S^+S,, 

A4 

IKf (S1,S2,S3) 

ADDITION,  rKS3+S^+S3 

AM 

D1,D^f  (DX,S) 

MULTIPLY 

DIVIDE 

AF 

Flags«-f  (S) 

BIT  TEST 

■ - - - -  -  —  ■  -  ■  — — - — - - 

COMPARE 


Modifying  flags  for  all 


arithmetic  and  logical  instructions 


Flags«-f (S1>S2) 
Flags+f  .  •  • ) 
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Not**  that  the  control  operations  in  RTL  control  statements  such  as 
conditional  branch  are  not  listed  because  ve  can  use  RTL  assignment  statements 
with  conditions  and  expand  the  RTL  description  for  instructions  with  loops. 

A  microprocessor  usually  can  be  divided  into  two  sections:  the  data 
processing  part  and  the  control  part  {2,11].  One  can  define  faults  for  each 
part.  In  this  paper,  we  emphasize  the  control  faults. 

A.  Data  processing  faults 

(1)  Data  storage  fault  (R)/(R)’ 

This  means  that  the  content  of  register  is  changed  from  (R)  to  (R) '  due 
to  faults  such  as  stuck-at,  bridging  and  pattern  sensitive  faults. 

(2)  Data  transfer  fault  •*-/■*■* 

The  fault  occurs  in  the  transfer  path  between  the  sources  and  the 
destination.  This  type  of  fault  includes  stucl:-at,  bridging  and  pattern  sensitive 
faults. 

(3)  Data  manipulation  fault  (f)/(f)' 

This  is  the  operation  execution  fault.  Under  this  fault,  the  operation 
f  is  executed,  but  the  result  of  operation  is  wrong. 

E.  Control  faults 

This  kind  of  fault  involves  register  decoding  faults,  instruction  decoding 
faults  and  other  control  faults.  A  register  decoding  fault  means  missing  or 
changing  the  selected  register,  or  selection  of  an  extra  register,  denoted  by 
R/i ,  R/F.',  and  R/R+R'  respectively.  For  instruction  decoding  faults,  we 
consider  that  an  instruction  can  be  executed  partially.  It  means  missing  or 
changing  the  selected  operation,  or  selection  of  an  extra  operation  in  RTL. 


In  this  case,  the  instruction  decoding  fault  mav  be  1./4,  1  /A1  ,  1  /A1  , 

J  j  j  j  k 

1  /I,  ,  I./AI.+AI.  ,  l./I.+AI,  ,  l./l.+l.  ,  and  so  forth  where  AI  means  part  of 
jkjjKjjkjjk 

instruction  1.  The  other  control  faults  include  instruction  execution 

sequence  faults,  condition  faults  and  so  on- 

From  the  above  observation,  we  assert  that  it  is  appropriate  to  represent 
the  control  faults  at  the  RTL  level.  Therefore,  ve  will  define  the  above 
control  faults  at  such  a  level.  Let  f  denote  IV-f (S^, S^, . . . ) ,  which  is  an  operation 
on  the  instruction-under-test,  and  fe{£},  where  {f}  is  the  set  of  RTL  operations 
ot  a  microprocessor.  Let  f'  denote  D'-*-f '  (S',  S^, . . . ) ,  which  is  an  unexpected 
(faulty)  operation,  and  f'e{f). 

We  now  define  three  classes  (i.e.  nine  subclasses  FI,  F2,  ...»  F°)  of 
control  faults  as  follows: 

(1)  f/<j)-  No  operation  is  executed. 

FI.  tn 

(2)  f/ff  -  Instead  of  performing  operation  f,  another  operation  f'  is 
executed.  It  contains  two  subclasses  of  faults. 

F2.  £ f /f 1 :  Here  £  means  that  the  destination  registers  D  and  E'  are 
different  and  the  fault  is  f/f'. 

F3.  of /f * :  o  denotes  that  registers  E  and  r'  are  the  same. 

(3)  f/f+f'  -  In  addition  to  operation  f,  another  operation  f'  is  also 
executed.  It  can  be  subdivided  as  follows. 

(3a)  Registers  D  and  D'  are  different. 

F4.  6f/f+f * :  The  source  register  list  of  f  and  f'  does  not  include 
D’  and  D  respectively.  We  are  not  concerned  with  the  execution  order 


p 

i 


F5.  6 f / f f f ;  The  source  register  list  of  f  includes  D'.  f’  is  executed 

before  performing  operation  f;  i.e.  the  execution  order  is 

1.  DW  (S',  S’,...) 

2.  D-f  (S1,S2 . D’*) 

where  register  without  *  denotes  its  content  before  executing  the  operation, 
register  with  *  denotes  its  content  after  executing  the  operation. 

F6.  6f/ff' :  The  source  register  list  of  f ’  includes  D  and  the  execution 

order  is 

1.  IX-f  (S1,S2,...) 

2.  D’-f’  (S’,S’,...,D*) 


(3b)  Registers  D  and  D'  are  the  same.  When  the  source  register 
list  of  f  and  f'  does  not  include  D'  and  D  respectively,  if  the  execution  order 
is  f’f,  the  fault  does  not  affect  the  execution  of  f.  If  the  execution  order  is 
f  f',  it  is  the  sane  as  the  case  with  the  fault  of/f'. 

F7.  cf/f *f :  The  source  register  list  of  f  includes  D,  and  the  execution 

order  is 


1.  IX-f'  (Sj,S’,...) 

2.  IX-f  (S1,S2 . D*) 

F8.  of / f f * ;  The  source  register  list  of  f  includes  D  and  the  execution 


order  is 


1.  D-f  (S1,S2,...) 

2.  IX-f'  (Sj,S’ . D*) 

F9.  tf/fli * :  Both  f  and  f'  are  executed  at  the  sane  tine. 

IX-f  (S^, Sj, . . . ) 

IXf’  (sj.sj,...) 

where  L  denotes  logical  AND  or  OR  function  depending  on  the  circuit  implementation 


In  this  case,  the  final  content  of  the  destination  D  is  the  result  of  the 
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composite  value  (i*e.  the  result  of  the  AND  or  OR  function)  of  f  and  f'. 

Note  that  the  above  control  faults  can  occur  at  any  place  in  an  instruction 
execution  sequence.  This  control  fault  model  can  cover  register  decoding  faults, 
instruction  decoding  faults  (including  partially  instruction  execution), 
instruction  execution  sequence  faults,  etc.,  since  any  control  fault  can  always 
be  defined  as  missing,  changing,  or  extra  RTL  opeations  and  will  cause  registers 
to  have  wrong  contents. 


Ill;  REQUIREMENTS  FOR  TESTING  CONTROL  FAULTS 
Oui  purpose  is  to  test  the  execution  of  microprocessor  instructions. 
Therefore,  the  objective  of  test  pattern  generation  is  to  find  the  initial 
data  in  registers  (test  data)  needed  for  testing  functions  of  an  instruction. 
This  test  data  must  satisfy  certain  requirements.  From  the  control  fault  model 
given  in  Section  II,  we  can  obtain  various  requirements  for  testing  control 
faults. 

Let  us  establish  the  following  notation.  For  a  fault-free  operation  f, 
we  have 

V  =  the  value  of  register  i. 

VS  *  the  value  of  the  operand  in  source  register  S^. 

VD  =  the  value  of  the  operand  in  destination  register  D. 

VD*  =  the  value  of  the  operation  result  stored  in  D. 

For  a  faulty  operation  f',  we  obtain  VSj,  VD'  and  VD’*  instead. 

Theorem  1.  Control  faults  T /$,  T/T'  and  T/T+T'  can  be  detected  if  the  data 
values  of  registers  satisfy  the  following  requirements: 

QTT1.  V1  i  V  ,  i  y  j 
QTT2.  \’i  L  V  i  Vi,  i  4  j 

Proof.  We  shall  prove  this  theorem  by  considering  the  nine  fault  classes 
defined  in  Section  II. 

(i)  For  fault  FI  (T /$)  and  F2  (6T/T'),  in  order  to  verify  transfer 
operation  T,  one  needs  VS  i  VD. 

(ii)  For  fault  F3  (oT/T’)f  the  results  of  T  and  Tf  should  be  different, 
i.e.  VD*  i  VD’*.  To  obtain  this  result,  we  must  have  VS  4  VS ’ . 

(iii)  For  fault  FA  (<$T/T+T')  and  F5  (6T/T’T),  we  need  only  to  detect  the 
extra  operation  T’.  Therefore,  VS  *  4  VD 1 . 


in 


(iv)  Fault  F6  (6T/TT')  means  that  transfer  operation  IKS  is  performed 
first,  then  In  order  to  detect  the  extra  operation  T',  one  needs 

VS  j  VP*. 

(v)  Fault  F7  (crT/T’T)  yields  IKS'  folloved  by  IKD*.  Therefore,  ve  obtain 
the  requirement  VS1  4  VD. 

(vi)  For  fault  F8  (OT/TT'),  we  have  IKS,  then  IKD*.  This  fault  does  not 
affect  operation  T.  In  order  to  verify  T,  ve  need  VS  4  VD. 

The  above  six  requirements  belong  to  QTT1. 

(vii)  For  fault  F9  (^T/TLI*),  the  composite  value  of  both  results  of  T  and 
T'  should  be  different  from  the  correct  result  of  T.  i.e.  VSLVS*  4  VS  which 
belongs  to  QTT2. 

O.E.P. 

Theorem  2.  Control  faults  T/A'  and  T/T+A'  can  be  detected  if  the  data  values 

of  registers  satisfy  the  following  requirements: 

QTA1.  V±  4  V  ,  i  4  j 

QTA2 .  f!  j*  VS 
A 

QTA3.  f!  i  VD* 

A 

QTA4.  VSLf[  +  VS 
A 

where  f*  is  the  result  of  operation  cf  class  A,  i.e,  f*  e  f *  (VS',  VS*,...). 

A  A  A  X  2 

Proof.  The  proof  is  similar  to  the  proof  for  Theorem  1,  Since  A'  instead 

of  T*  is  performed,  ve  can  change  VS'  to  f^  in  the  requirements  (ii),  (iii), 

(v)  and  (vii)  in  the  proof  For  Theorem  1  to  obtain  the  corresponding 

requirements  for  Theorem  2. 

(i)  For  F2  (ST/A'),  VS  4  VD,  (QTA1) . 

(ii)  For  F3  (0T /  A ' )  ,  VS  i  f',  (QTA2). 

_ A 

(iii)  For  FS  (6T/T+A*)  and  F5  (fT/A'T) ,  V  i  VD',  (QTA3) . 

(iv)  For  F6  (6T/TA'),  it  means  that  IKS  first,  then  D'--f!  (S' ,S' , . . .  ,I>*)  . 

A  12 
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We  need  (VS^.VS^  . VS)  4  VD'.  Since  VS  can  be  selected  as  any  initial 

data  value,  it  can  be  considered  as  one  of  several  source  operands.  Therefore, 

ve  can  rewrite  f'  (VS’  VS  I  ,...,VS)  4  VD*  as  f’  4  VD’,  (QTA3) . 

A  1  Z  __A _ 

(v)  For  F7  (cT/A'T),  f^  4  VD',  (QTA3) . 

(vi)  For  FB  (CT/TA'),  it  implies  D<-S  followed  by  D-f!  (S’  Si  , ...,P*). 

A  1 

This  requires  VS  4  f^  (VSj ,VS2 , . . . , VS) .  Here  VS  can  be  considered  as  a 

destination  operand  VD’.  So  we  rewrite  the  ineoualitv  as  VD'  4  f',(0TA3). 

_ A 

(vii)  For  FQ  (OT/TIA'),  VSLf^  1*  VS,  (QTA4 ) .  Q.F..D. 

Theorem  3.  Control  faults  A/<£,  A/T'  and  A/A+T'  can  be  detected  if  the  data 

values  of  registers  satisfy  the  following  inequalities. 

QAT1.  f  4  VD 

A 

QAT2.  f  f*  VS' 

A 

QAT3.  Vi  *  V  ,14  j 
QAT4.  f  4  VD' 

QAT5.  fA  (VS')  4  fA(VD) 

QAT6.  f,  I  VS'  4  f. 

where  fA  =  fA  (VS^VS^...),  fA<VD)  -  fA<VSl,VS2’ ’ *  * ,VP) ’  fA(VS')  = 

f  (VS,,  VS„ . VS’). 

A  1  2 

Proof.  Since  arithmatical  and  logical  operations  instead  of  transfer 
operations  are  considered  here,  we  can  change  VS  to  f  in  the  cases  (i),  (ii), 
(iv),  (vi)  and  (vii)  of  Theorem  1. 

(i)  For  FI  and  F2,  f  4  VD,  (QAT1) . 

(ii)  For  F3,  fA  4  VS’,  (QAT2) . 

(iii)  For  F4  and  F5,  VS’  4  VD’.  (QAT3) . 

(iv)  For  F6,  f  4  VD’,  (QAT4) . 

(v)  F7  (aA/T’A)  means  that  D«-S '  followed  by  D«-fA ^Si»S2 . . * )  which  yields 

fA(VSi.  VS2,...,VS’).  When  there  is  no  fault,  fA(VS^,  VS2,...,VD)  is  obtained. 
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Thus  the  condition  for  detecting  this  fault  is  fA(VS,,  VS„, . . . ,VS* ) 

A  1 _ 2 

i  fA(VS1,VS2 . VD ),  (QTA5) . 

(vi)  For  F8,  ft  +  TO,  (QTAl) . 

A _ 

(vii)  For  F9,  f  L  VS’  +  f  ,  (QTA6).  Q.E.F. 

Theorem  4.  Control  faults  A/A'  and  A/A+A’  can  be  detected  if  the  data  values  of 
registers  satisfy  the  following  inequalities. 


QAAl. 

f.  i  TO 

A 

QAA2. 

v f; 

QAA3. 

f’  i  TO’ 

A 

QAA4. 

f;(V  + 

QAA5. 

fA  (f;>  k  fAcvD) 

QAA6. 

f;.  <v  * f  a 

QAA7. 

fA  1  fl  *  f A 

where  f^)  *  f^(VSj,  VS»#...,fA>,  f^f'J  -  f^VS^VSj . f'A). 

Proof.  For  the  same  reason,  we  cay  change  VS  to  fA,  and  VS’  to  fj  for 

*  A  A 

cases  (i)  to  (iii)  and  (vii)  in  Theorec  1  to  obtain  QAA1  to  0AA3  and  QAA7 

respectively.  In  addition,  since  the  results  of  A  and  A’  may  affect  each  other, 

we  can  obtain  QAA4  to  QAA6.  Q.E.D. 

Note  that  for  requireEent  QAA7,  if  operation  f.  and  f'  of  class  A  are 

A  A 

executed  in  the  same  unit  (e.g.  AIl:)»  then  both  results  cf  fA  and  f'  can  no 

A  A 

longer  be  considered  as  obtained  separately.  Instead,  QAA7  may  be  considered 
as  a  data  manipulation  fault  (f  )/(f  )’. 

A  A 
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IV.  WRITE  AND  READ  SEQUENCES 

As  a  microprocessor  is  one  type  of  sequential  machine  and  all  internal 
registers  are  memory  elements  of  the  sequential  machine,  the  content  of  registers 
represents  the  state  of  the  sequential  machine.  Therefore,  the  following  general 
procedure  is  utilized  for  testing  microprocessors. 

1.  Initialization  of  state  of  registers. 

2.  Execution  of  the  instruction-under-test. 

3.  Read  the  state  of  registers. 

In  fact,  Steps  1  and  3  consist  of  write  and  read  register  sequences  respectively. 
Obviously,  if  ve  can  guarantee  the  correctness  of  Steps  1  and  3  first,  then 
the  testing  problem  will  be  simplified. 

The  testing  approach  used  here  is  a  kind  of  open  loop  testing  [5].  It 
implies  the  use  of  a  test  equipment  which  provides  the  stimuli  to  the  micro¬ 
processor  and  observes  the  responses  from  the  microprocessor. 

Now  let  us  discuss  write  and  read  sequences  which  are  used  for  writing 
and  reading  the  register  states  of  a  microprocessor.  They  consist  of  several 
basic  instructions,  called  the  kernel  of  microprocessor.  These  instructions 
of  the  kernel  can  be  carried  out  by  a  sequential  machine,  therefore,  we  can 
use  a  checking  experiment  to  verify  the  kernel. 

A.  The  kernel  of  microprocessor 

Definition  1.  Kernel  instruction  set  -  A  small  subset  of  instructions  of  a 
microprccesscr  vhich  can  be  used  for  constituting  the  write  and  read  register 
sequences . 

Definition  2.  Register  set  -  All  internal  registers  of  a  microprocessor  from  the 
view  of  the  architecture  or  programming. 

Definition  3.  Kernel  state  -  The  register  state,  i.e.  certain  set  of  data  values 


of  the  registers. 


Definition  4.  Kernel  input  -  The  write  sequence  for  writing  a  set  of  data  into 
the  registers,  or  the  read  sequence  for  reading  out  the  contents  of  the  registers. 
Definition  5.  Kernel  output  -  The  set  of  data  values  of  the  registers  which  are 
read  cut  by  the  read  sequence. 

B.  Kernel  instruction  set 

There  exists  many  choices  for  the  kernel  instruction  set.  In  order  to 
keep  the  kernel  srall,  the  following  requirements  should  be  satisfied. 

1.  The  number  of  instructions  in  the  kernel  instruction  set  should  be 

small. 

2.  Functions  of  each  kernel  instruction  should  be  as  simple  as  possible. 

For  instance,  a  kernel  instruction  contains  mainly  transfer  type  of  operations, 
or  small  number  of  RTL  operations. 

3.  In  order  to  simplify  addressing,  the  priority  order  of  choosing  the 
addressing  mode  of  an  instruction  is  as  follows. 

.  For  write  register  instructions:  Immediate,  Direct,  Indirect. 

.  For  read  register  instructions:  Direct,  Indirect. 

For  the  existing  off-the-shelf  microprocessors,  most  registers  can  be 
written  into  or  read  from  directly.  These  registers  are  called  direct  access 
registers.  Others  are  indirect  access  registers  which  can  be  accessed  through 
the  direct  access  registers  in  certain  order  by  using  transfer  instruction 
among  registers. 

C.  Kernel  state 

In  order  to  simplify  the  testing,  during  the  checking  experiment,  we  only 
use  a  few  states  for  the  good  kernel,  i.e.  we  define  several  sets  of  data  values 
for  the  registers.  Therefore,  we  should  choose  the  data  values  (test  data) 
such  that  they  can  cover  as  many  faults  as  possible. 


V.  TEST  DATA 


We  use  the  checking  experiment  tc  verify  the  kernel  cf  e  microprocessor. 

The  main  task  is  to  decide  hov  many  states  of  the  kernel  and  vhat  test  data  we 
use . 

Abraham  and  Parker  [5]  use  the  U-out-of-r.  codes  for  their  "register  read 
test"  procedure,  where  m  is  the  width  of  a  code  word  (i.e.  the  length  of  register), 
and  k  is  the  number  of  l's  in  the  code  word.  As  ve  will  see,  this  type  of  code 
is  powerful  since  it  can  be  used  as  test  data  to  cover  most  control  faults  by 
using  fewer  data.  We  will  use  the  k-out-of-m  codes  for  verifying  the  write 
and  read  sequences  as  well  as  for  testing  control  faults.  The  k-out-of-tn  codes 
can  also  detect  stuck^at  type  faults,  but  do  not  guarantee  to  cover  all  data 
processing  faults. 

To  simplify  the  testing,  we  *’111  only  use  transfer  operations  of  the  kernel 
instructions  in  write  and  read  sequences.  Therefore,  we  only  need  to  consider 
the  requirements  of  Theorems  1  and  2, 

A.  QTT1,  QTA1  and  QTT2 

The  k-out-of-n  codes  used  as  test  data  can  satisfy  requirements  QTT1, 

QTA1  and  QTT2  (X±  ¥  X ^  and  V±  L  V  i  X ±) .  This  is  because  in  the  k-out-of-m 
codes,  all  code  w’ords  are  distinct  and  the  AND (OR)  operation  cf  any  two  code 
words  will  decrease  (increase)  the  number  of  l's  in  the  code  word,  therebv  the 
new  code  generated  is  different  from  both  original  code  words. 

B.  QTA2 

The  requirement  0TA2,  f'  ¥  VS,  is  for  detecting  fault  rl/A'.  Here  D  and 

Pi 

D'  are  the  same  register.  During  the  checking  experiment  for  the  kernel,  there 
exists  an  input  leaving  the  kernel  state  unchanged,  i.e.,  the  transfer  operation 
1  (in  write  sequence)  keeps  VD  (=YD')  unchanged.  Thereforc.fi  ¥  VS  becomes 
f'  ¥  VS  =  VD  =  VD'  which  belongs  to  0TA3. 
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C.  QTA3 

The  requirement  QTA3,  f^CVSjfVS^, . . . )  4  VD’,  is  for  detecting  an  extra 
operation.  We  list  the  restrictions  of  operands  (test  data)  for  detecting 
operation  of  class  A  in  Table  2. 


Extra  Operations 

Restrictions  of  Operands 

BIT  SET 

<D 

BIT  RESET 

0) 

BIT  COMPLEMENT 

No 

INCREMENT 

No 

DECREMENT 

No 

DECIMAL  ADJUST 

<3) 

SHIFT 

4  0  (all  Rs),  1  (all  Is) 

ROTATE 

*  o,  i 

COMPLEMENT 

No 

NEGATE 

No 

CLEAR 

4  0 

ADDITION 

4  o 

ADDITION  WITH  CARRY 

4  o,  -1 

SUBTRACTION 

4  o 

SUBTRACTION  WITH  BORROW 

4  o,  -l 

AND 

k-out-of-m  codes 

OR 

k-out-of-m  codes 

XOR 

k-out-of-m  codes 

EXTENT  SIGN 

4  o,  l 

ADDITION,  D«-S  +  S2 

the  least  significant  bit  LSD  *1 

ADDITION,  D«-r  +  S.  +  S„ 

4  0;  VS’  +  VS;  4  0 

ADDITION,  EH-Sj  +  s2  +  S3 

© 

MULTIPLY 

4  o,i 

DIVIDE 

4  o,  l 

BIT  TEST 

(D 

COMPARE 

© 

Modifying  flags 

Table  2.  Restrictions  of  operands  for  detecting  faulty 
arithmetic  or  logical  operations 


©  If  ve  use  two  tests  in  which  the  source  operands  are  complements  of 
each  other,  then  one  of  the  tests  can  detect  the  faulty  operation. 

(D  These  operations  only  set  or  reset  the  flags.  Ve  use  two  tests  with 
the  identical  source  operands  and  two  sets  of  flags  which  are  complements  to  each 
other.  The  faulty  will  change  one  of  the  flags. 

(5)  The  execution  of  DECIMAL  ADJUST  (to  add  certain  values)  depends  on  the 
value  of  source  operand  and  the  flags.  Ve  can  use  either  method  in  case  1 
or  either  method  in  case  2  to  detect  the  operation. 

©  Operation  D*-S^  +  ^2  +  ^3  *s  on^’  use<^  for  oemory  address  addition. 

Here  D  means  external  address  bus.  In  thi6  case,  the  unexpected  operation 
does  not  affect  the  write  and  read  registers.  Hence  it  needs  not  to  be 
considered  for  verifying  the  kernel. 

(D  During  the  checking  experiment  for  the  kernel,  if  we  have  considered 
the  main  operations  in  arithmetic  and  logical  instructions  as  the  unexpected 
operation,  then  we  need  not  consider  modifying  flags  which  are  auxiliary 
operations. 

For  other  operations,  the  restrictions  are  obvious.  For  example, 

ADDITION  WITH  CARRY,  D'«-D'  +  S'  +  CARRY  ,  if  CARRY  =  0  with  the  restriction 
VS'  0  or  CARRY’  =  1  with  the  restriction  is  VS'  4  -1,  then  VD'*  4  VD'. 

Since  we  use  k-out-of-m  codes  as  operands,  these  restrictions  can  be  satisfied. 
For  operation  D'-*-D'  +  S^  +  S^  ,  since  the  negative  value  of  any  k-out-of-m 
code  word  will  not  be  any  k-out-of-m  code,  i.e.  VS.'  +  VSj  4  0;  so  VD’  +  VSj  +  VSl 
4  VD'.  For  operation  D'«-S^  +  Sj»  we  can  divide  the  k-out-cf-c  codes  into  two 
groups  with  different  LSB  (Least  Significant  Eit).  These  two  groups  complement 
each  other.  The  group  with  the  restriction  LSB  =  1  will  be  used  for  testing. 


IS 


For  operation  ROTATE,  the  restriction  is  for  the  case  of  the  odd  number  of 
shifted  bits.  Otherwise,  we  need  otha: restriction  (e.g.  using  subset  of 
k-out-of-o  codes  as  operands). 

D.  QTA4 

The  checking  experiment  does  not  guarantee  requirement  QTA4,  VS  f  F^  VS. 

For  example,  for  the  normal  transfer  operation  T,  IKS,  with  VS  =  111000,  VD  =  011100 

(using  3-out-of-  6  codes),  if  there  exists  a  fault  CT/TLA.'  and  the  extra 

operation  A*  is  SHIFT  LEFT,  EH-SHL  D,  then  f)  =  111000.  If  L  is  an  AND  function, 

then  VS  I  f'  =  VS.  Thus  0TA4  cannot  be  satisfied.  Therefore,  we  need  another 
A 

test  procedure  to  remedy  this.  The  remedy  is  to  change  the  value  of  S  in  the  operation 

D^-S  to  1  or  0  depending  upon  L  being  AND  or  OR  respectively.  From  the  above  example, 

we  see  that  if  I  is  an  AND  function,  let  VS  =  1  then  QTA4  becomes  f!  ^  1  which 

—  A  — 

can  be  satisfied.  Similarly,  if  L  is  an  OR  function,  let  VS  ■=  0^  and  QTA4  changes 

to  f»  y  0. 

A  — 

Nov*  let  us  check  this  remedy  method  for  all  operations  of  class  A.  Note 
that  we  only  change  the  value  of  S  in  operation  IKS,  and  D'  in  operation  A.'  can 
be  substituted  by  D. 

(i)  For  class  Al,  IKf’(D).  If  ve  use  k-out-of-m  codes,  the  new 

A 

requirement  OTA 4  * ,  f^  i  1_  (£) ,  depending  or.  I,  can  be  satisfied  except  the 
operation  CLEA.F.  with  I  being  OR.  But  in  this  case,  the  result  of  V  is  always 
£  which  does  not  affect  the  operation  IKS . 

(ii)  For  class  EKf^(D,S’).  No  matter  S'  is  the  same  register  as  S 
or  not,  QTA4'  is  true  except  the  following  case:  when  S'  and  S  are  the  same 
register,  then  for  QTA4',  f^  +  1  (f^  is  operation  CR  and  L  is  AND)  and  f^  4  0 
(f'  is  operation  AND  and  L  is  OR)  cannot  be  met.  But  in  this  case,  if  S’  and 

A 

S  are  the  same,  VSIf^  is  always  the  same  as  VS,  the  fault  docs  not  affect  D^S, 
i.e.  VSA(VDWS)  =  VS  and  VSV(VDAVS)  =  VS  for  any  operands  D  and  S. 


(iii)  For  the  EXTEND  SIGN  operation,  EH-f'(S'),  the  result  of  f*  is  0  or  1. 

A  A  —  — 

Similarly  vith  case  (i),  either  QTA4  can  be  met  or  the  fault  does  not  affect 
operation  T. 

(iv)  Fcr  classes  A3  and  AF,  QTA4  can  be  satisfied.  For  the  same 

reason  as  QTA3,  we  need  to  consider  neither  modifying  flags  operation  nor 

IH-S.  +  S„  +  S_. 

1  l.  3 

(v)  For  MULTIPLY  and  DIVIDE,  since  the  execution  period  of  these  operations 
generally  is  longer  than  that  of  transfer  operations,  fault  ctlf.LV  cannot  exist 
and  we  do  not  consider  0TA4. 

In  summary,  during  the  checking  experiment  we  only  need  three  sets  of 

test  data  for  internal  registers.  Let  n  be  the  number  of  the  internal  registers. 

t  be  the  length  of  registers.  Suppose  that  m  is  even.  Let  V  denote  a  complete 

set  of  k-out-cf-m  code  words.  Usually,  k  =  y.  IvJ  =  (  will  be  the  maximum 

number  of  distinct  codes.  We  divide  them  into  two  groups,  and  with  different 

LSB .  These  two  groups  are  complementary  to  each  other.  Note  that  for  most 

microprocessors,  n  is  even,  and  ]v|  >  2n. 

Let  {a}  =  (a  ,a  ,...,a  },  {a}  =  ,cx-,. .. ,q  },  {a}  and  {a}  belongs  to 

1  /  r.  1  «:  n 

V  ar»c  V,  respectively.  We  now  construct  four  sets  of  data  as  follows. 

~V  j. 

i  Flag  register  Other  registers 

i 

i 

l 

i 

i 

] 

In  order  to  satisfy  requirement  OTA 3,  we  can  choose  any  three  sets  of  data  as 
the  initial  values  of  registers  (test  data).  In  fact,  one  needs  a  few  more 
date  as  external  bus  inputs  during  testing.  Therefore,  the  final  number  of  code 


words  in  {a}  and  {a}  is  larger  than  n. 

It  should  be  pointed  out  that  the  program  counter  (PC)  is  easy  to  test.  W 
can  put  a  direct  addressing  branch  instruction  at  the  end  of  a  write  sequence. 
This  instruction  stores  a  particular  value  into  PC,  then  the  content  of  PC  is 
checked  at  the  beginning  of  the  read  sequence  by  observing  the  address  bus. 

VI.  VERIFYING  WRITE  AND  READ  SEQUENCES 

Now  we  will  derive  the  checking  sequence  for  the  kernel.  As  we  mentioned 
before,  we  only  use  three  sets  of  test  data  for  the  kernel,  namely  a,  b  and  c. 
First  of  all,  just  like  a  sequential  machine  we  have  to  obtain  a  flow  table  of 
the  kernel.  We  consider  two  cases. 

Case  1.  For  a  microprocessor  without  indirect  access  registers,  we  obtain 
the  following  flow  table. 


A  0 

A  Q 
A  ® 


B  © 

b  CD 

B  0 


C  0 
C  0 

c  0 


A,  a  (Id) 

B, b  (n) 

c,c  (T2) 


Case  2.  For  a  microprocessor  v’ith  indirect  access  registers,  we  obtain 
the  following  table. 


w 

a 

Kb 

w 

c 

R 

A  0 

B  0 

c  © 

A*  ,a  (Td) 

A  0 

B  0 

c  © 

B*  ,b 

A  0 

B  0  ! 

c  dD 

C*  ,c  0D 

A  © 

B  (10) 

c  © 

A*  ,a*  © 

A  0 

B  (n) 

c  © 

B*  ,b*  © 

A  © 

B  © 

c  © 

C* ,c*  <© 

where  W  ,  V,  ,  V  -  write  sequences  for  writing  a,  t  and  c  respectively, 
a  b  c 

F  -  read  sequence. 

A,  B,  C,  A*,  B*,  C*  -  Kernel  states.  A,  E  and  C  are  the  states  after 
applying  the  corresponding  write  sequences  V£,  V^.  A*,  B*  and  C*  are  the 

states  after  applying  read  sequence  R. 

a,  b,  c,  a*,  b*,  c*  -  Kernel  output  sequences  produced  by  read  sequence  R 
for  states  A,  B,  C,  A*,  B*,  C*  respectively. 

( i )  denote  the  state  transition  i. 

Since  we  only  use  three  sets  of  test  data,  the  number  of  states  of  the  kernel  is 
constant.  It  means  that  the  above  flow*  tables  are  independent  of  microprocessors 
Therefore,  we  can  easily  obtain  the  checking  sequences  with  the  same  form. 

There  are  three  requirements  to  derive  a  checking  sequence  [1?] 

1.  Initialization  of  the  machine  (kernel)  state  using  sychronizing 
sequence  or  homing  sequence. 

2.  Identify  all  machine  states  using  distinguishing  sequence. 

3.  Verify  each  transition  using  distinguishing  sequence. 

For  our  kernel,  there  exists  svchronizing  secuences  V  or  V,  or  V  and 

a  b  c 

distinguishing  sequence  R.  Therefore,  we  can  easily  derive  checking  sequences 
as  follows. 


Checking  Sequence  1  (for  case  1) 

Initialization 

/ 


Identify  all  states 


©@<Q(D®(D  ©  ©  ©  (D  (5) 

\  i  ♦  * 


Verify  all  state  transitions  (i.e.  next  states). 
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Checking  sequence  2  (for  case  2) 
Initialization 


Identifv  all  states 

I  !  \  \ 


'-r  V*  ^  ^  s*'  V* 

©  ©  ©©!©  ©  ©  © 
14  1  4  4  ... 

Verify  all  state  transitions  (i.e.  next  states) 


R  R  H, 

t  b 

\V 

©  © 


R  V 

a 


© 


R  V  R 

a 

© 


V  V  R  K  l’  R  V.  V,  R  V.  v;  R  V  W  R  V  V  R  V  V  R  V  K  R  V.  V  R 
aa  ab  bb  be  cc  ca  ac  cb  ba 

^  ,yV  V  W  ^  W  V*» 

©  (z)  d>  G>  ©  ©O  ®  © 

Finally,  we  can  obtain  two  test  procedures  for  verifying  the  write  arc  read 
sequences  as  follows. 

Procedure  1:  Checking  experiment 

1.  If  a  microprocessor  does  not  have  indirect  access  registers,  ve  use 
checking  sequence  1. 

2.  If  a  microprocessor  has  ind_rect  access  registers,  we  use  checking 
sequence  2. 

Procedure  2:  Remedy  testing 

For  each  of  the  three  sets  of  register  values  a,  b  and  c,  do  the  following 
for  each  register. 

1.  Initialization  of  all  registers. 

2.  Vrite  1_  or  £  into  the  given  register  depending  on  the  circuit 
implementation. 

3.  Read  the  given  register. 

Therefore,  from  the  previous  discussion  in  this  section,  we  obtain  the  following 
theorem. 

Theorem  5.  Procedures  1  and  2  can  verify  write  and  read  sequences,  ar.d  after 
that  the  registers  of  a  microprocessor  can  be  initialized  to  any  values. 
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VII.  TESTING  CONTROL  FAULTS 

During  the  verification  of  the  correctness  of  write  and  read  sequences, 
we  are  only  concerned  with  certain  transfer  operations  (not  all  RTL  operations) 
in  the  kernel  instructions.  Therefore,  when  we  test  instruction  decoding  and 
other  control  faults,  we  need  to  test  all  instructions  included  in  the  kernel. 
Note  that  obviously,  register  decoding  faults  can  be  detected  by  verifying  write 
and  read  sequences  using  the  k-out-of  m  codes. 

Procedure  3.  Testing  instruction  decoding  and  other  control  faults 

For  each  instruction,  do  the  following  test, 

1.  Initialize  register  state  using  any  particular  initial  values. 

(test  data) 

2.  Execute  the  instruction-under-test. 

3.  Read  register  state. 

Note  that  we  should  first  try  to  use  three  sets  of  data  values  a,  b  and  c 
at  Step  1. 

Generally  we  need  several  tests  for  each  instruction  to  detect  the 
instruction  decoding  and  other  control  faults.  Obviously,  the  lower  bound 
of  the  number  of  tests  using  Procedure  3  for  each  instruction  is  two.  This 
is  because  any  kind  of  microprocessors  has  several  pairs  of  conditional  branch 
instructions  based  on  two  different  values  for  the  same  condition  sourse . 
Therefore,  when  any  instruction  is  under  test,  in  order  to  detect  an  unexpected 
branch  instruction  due  to  a  fault,  we  need  at  least  two  test  patterns. 

The  upper  bound  on  the  test  for  each  instruction  is  dependent  upon  the 

microprocessor-under-test.  We  can  roughly  estimat  the  order  of  tests  for 

detecting  instruction  decoding  faults.  We  consider  n^  instructions  to  be 

tested,  assume  that  each  instruction  corresponds  to  an  operation,  class  T  or 

Class  A,  used  for  distinguishing  instructions  fro-  each,  other.  Let  n 

n  denote  the  number  of  instructions  which  have  operations  class  1  and 
i/i 


and 
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class  A  respectively,  i.e.  =  n^  +  n^. 

A.  Testing  Instruction  class  T 

1.  The  case  of  Theorem  1 

Since  for  some  condition  branch  instructions,  their  operations  belong  to 
class  T,  and  they  are  condition  transfer  operations.  In  order  to  detect  this 
unexpected  operation  T',  tvo  tests,  in  which  test  data  are  complement  to  each 
other,  are  sufficient. 

2.  The  case  of  Theorem  2 

First  of  all,  we  use  three  sets  of  initial  values  a,  b  and  c  for  satisfying 
the  requirements  QTA1  and  QTA3.  In  order  to  satisfy  QTA2  and  QTA4,  we  can 
modify  a,  b  and  c  separately  as  new  test  data.  As  we  have  discussed  in 
Section  V,  if  the  instruction-under-test  has  a  transfer  operation  IKS,  we  can 
change  VS  in  original  data  a,  b  and  c  to  VD,  then  QTA2  becomes  QTA3  which  can 
be  satisfied.  Similarly,  we  can  change  VS  to  1^  (or  0 )  to  satisfy  QTA4.  Here 
we  need  nine  tests  altogether.  Thus,  the  order  of  the  number  of  tests  for 
testing  instruction  class  T  is  0(nIT). 

B.  Testing  instruction  class  A 

1.  The  case  of  Theorem  3 

Test  data  a,  b  and  c  can  cover  QAT1  and  QAT3.  Similarly,  in  order  to 
satisfy  QAT2,  QAT4,  QAT5  and  QAT6,  we  can  modify  a,  b  and  c  in  turn.  First, 
we  change  VS'  and  VD'  to  VD  for  covering  QAT2  and  QAT4  respectively.  These 
changes  are  done  for  each  register,  so  it  needs  3n  tests,  where  n  is  the  number 
of  registers.  Then  we  change  VS’  to  a  particular  value  for  covering  QAT5  and 
QAT6  separately.  It  needs  6n  tests.  So  the  total  number  of  tests  for  each 
instruction  in  this  class  will  be  9n+3. 

2.  The  case  of  Theorem  4 


We  need  three  tests  using  a,  b  and  c  for  covering  QAA1  and  QAA2. 


Then  we  atteept  to  find  five  particular  tests  to  satisfy  QAA3  through  QAA7  for 


each  unexpected  operation  A*.  So  the  number  of  tests  for  each  instruction  in 

this  class  will  be  3  +  5  (n_ .  -1)  =  5  n  -2. 

IA  1A 

Therefore,  the  order  of  the  number  of  tests  for  testing  instruction  class 

is  0  (n*n^  +  n^) .  The  order  of  the  number  of  tests  for  testing  instruction 

2 

decoding  and  other  control  faults  is  0  (n  +  n.n  +  n  ).  Note  that  using 

i  1  lA 

Thatte  and  Abrahair.'s  approach  [3],  the  order  of  the  number  of  tests  for  testing 


instruction  decoding  faults  is  0  (n"). 
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VIII .  CONCLUSION 

Any  deterministic  functional  testing  approach  for  microprocessors  always 
involves  the  initialization  and  the  reading  of  internal  registers  in  each  test, 
i.e.  write  and  read  sequences.  If  we  devide  the  testing  into  two  steps  and 
guarantee  the  write  and  read  sequences’  correctness  first,  then  the  complexity 
of  test  generation  will  be  reduced. 

Since  control  faults  possibly  lead  to  the  partial  execution  of  an  instruction 
or  changing  the  execution  sequence,  we  assert  that  it  is  reasonable  to  define 
a  control  fault  model  at  the  RTL  level  instead  of  the  instruction  level. 

For  test  generation,  usually  one  derives  a  test  for  a  given  fault.  But  if 
we  find  a  test  to  cover  as  many  faults  as  possible,  then  test  generation  will 
be  more  efficient.  It  seems  that  the  k-out-of-m  codes  for  test  data  are  quite 
powerful . 

The  function  of  write  and  read  sequences  can  be  modeled  as  a  small  sequential 
machine  which  is  almost  independent  of  microprocessors.  Therefore,  we  can  easily 
use  the  checking  experiment  to  verify  the  sequential  machine. 

Further  work  includes  the  enumeration  of  the  control  faults  at  the  RTL  level 
for  the  generation  of  tests  to  cover  all  possible  faults. 

In  addition,  for  the  data  processing  part  of  a  microprocessor,  it  is  easy  to 
handle  storage  faults  and  transfer  faults.  For  data  manipulation  faults,  it 
seems  that  the  best  way  is  to  find  a  set  of  test  patterns  to  exercise  each 
operation  based  on  the  analysis  of  logic  function  of  the  operation,  or  simply 
use  random  data  (locally). 

Combining  the  simplified  functional  testing  method  with  the  signature 
analysis  technique  may  be  a  good  approach  for  implementing  the  Built-In  Self 
Test  (BIST)  of  microprocessors. 
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ABSTRACT 

This  paper  presents  a  nev  algorithm  for  func¬ 
tional  test  generation  of  digital  LSI/VLSI  systems. 
First,  a  register-transf er  (RT)-leve!  fault  model 
is  developed  based  on  a  veil-defined  register- 
transf  er-language  (RTL'».  The  analysis  and 
collapsing  of  faults  in  RT-level  fault  model  were 
performed.  Then,  the  RT-level  symbolic  execution 
technique  is  employed.  The  major  problems  en¬ 
countered  are  defined,  analyzed  and  solved.  Final¬ 
ly,  an  explicit  algorithmic  test  generation  algo¬ 
rithm.  is  developed.  This  practical  algorithm 
applies  software  skills  in  hardware  testing.  It 
is  easy  to  be  automated  and  hence  provides  a 
promising  sclutior.  for  future  testing  problems  of 
digital  LSI/VLSI  systems. 

1,  INTRODUCTION 

Due  to  the  rapidly  Increasing  complexity  of 
modem  LSI/VLSI  devices,  functional  testing  has 
received  more  attention  than  ever  [l-3‘.  The  high 
complexity  of  VLSI  makes  conventional  gate-level 
testing  very  difficult  and  expensive  to  perform. 
Techniques  for  design-for-testability  (DFT)  or 
built-in-self-test  (BIST)  consider  the  testing  pro¬ 
blem  during  the  design  stage  of  digital  devices 
with  the  objective  of  reducing  the  test  complexity. 
However,  these  approaches  are  not  applicable  to  the 
existing  off-the-shelf  components  (e.g.,  Z-80,  8080). 
Function-level  testing  is  another  promising  solution 
to  solve  these  problems.  Functional  testing  can  be 
used  tc  assure  proper  operations  of  a  system  with 
off-the-shelf  components  and  tc  "test"  (and  hence 
improve)  a  digital  system  even  in  its  design  phase. 

Functional-testing  uses  a  representation  of  a 
digital  system,  higher  than  the  gate-level  testing. 

In  functional  testing,  functional  faults  with  re¬ 
spect  tc  the  functional  specification  (e.g.,  addi¬ 
tion  operation  in  a  processor)  are  tested  instead 
of  signal  faults  (e.g.,  stuck-at-0)  at  the  Inputs 
and  the  output  of  a  logic  gate  or  interconnections 
among  gates  in  gate-level  testing.  The  purpose  cf 
functional  testing  is  to  validate  correct  functional 
operations  of  digital  systems  according  tc  their 
spec  if ications .  Using  functional  testing  techniques, 
one  cannot  only  reduce  the  test  generation  complexity 
but  also  obtain  a  test  set  for  testing  the  digital 
devices  with  the  same  functions  but  different  cir- 

*  This  work  is  supported  by  the  United  States  Amy 
Communicat  Ion  Electronics  Conrrand  under  Research 
Contract  No.  DAAB  0T-82-K-J05S . 


cult  design/ implementation  (e.g.,  parallel  adder 
vs.  serial  adder).  Especially  for  the  users  of 
LSI/VLSI  chips,  they  have  little  other  alternative 
but  functional  testing  since  the  chips'  design/ 
implementation  details  are  usually  considered  pro¬ 
prietary. 

Several  functional  testing  techniques  have 
been  proposed  today.  Su  and  Lin  j 3[  recently  over¬ 
viewed  most  of  the  major  techniques  in  literature. 
Shen  and  Su  i  4  [  discussed  the  major  issues  involved 
in  functional  testing  of  microprocessors.  Brahme 
and  Abraham  [51  proposed  a  new  fault  model  for  the 
control  ar.d  instruction  decoding  faults  to  increase 
the  practicality  of  their  previous  approach  [151. 
Based  on  the  observations  obtained  in  [3[,  most,  if 
not  all,  of  the  existing  techniques  need  further 
development.  There  are  still  a  lot  of  open  prob¬ 
lems  which  need  to  be  solved. 

In  this  paper,  a  new  algorithm  to  systematically 
perform  functional  test  generation  for  digital  LSI/ 
VLSI  systems  using  machine  symbolic  execution 
technique  is  presented.  The  digital  system  under 
test  is  described  by  the  popular  register  transfer 
language  (RTL) .  This  technique  is  based  on  two  major 
foundations.  First,  after  a  standard  syntax  of  a 
register  transfer  statement  is  defined,  a  compre¬ 
hensive  RT-level  fault  model  is  set  up.  All  types 
of  faults  covered  by  the  fault  model  are  analyzed 
and  the  number  of  fault  cases  is  reduced.  Mere 
practical  faults  than  other  techniques  are  included 
in  this  fault  model.  Secondly,  based  on  the  RT- 
level  fault  model  derived,  the  technique  c:  symbolic 
execution  which  is  intensively  developed  in  high- 
level  programming  languages  is  employed  in  RT-level 
test  generation.  Symbolic  execution  is  a  kind  of 
program  execution  technique  which  manipulates  sym¬ 
bolic  variables  instead  of  variable  values  during 
program  execution.  Since  the  syntax  structure  and 
operational  complexity  of  RT-statements  are  much 
simpler  than  those  of  higher  level  languages,  the 
problems  of  symbolic  execution  encountered  in  R7- 
level  are  less  complex.  Basically,  the  symbolic 
execution  is  performed  on  both  fault-free  and  fault- 
injected  machines.  By  comparing  the  symbolic  results 
and  path  constraints  obtained  from  fault-free  and 
fault-injected  machines,  che  input  test  patterns  to 
distinguish  "bad"  machines  from  "good"  ones  can  hence 
be  derived. 

The  formal  syntax  definition  of  the  standard 
register  transfer  statement  ! RT-statement )  is  giver 
in  Section  I.  Section  3  presents  the  analysis  anc 
collapsinc  of  the  RT-level  faults.  The  basic  pro- 


blems  of  machine-level  symbolic  execution  and  their 
solutions  are  described  in  Section  4.  Section  5 
outlines  the  steps  in  the  overall  test  generation 
algorithm  and  explains  the  key  ideas  within  each 
step.  Finally,  a  brief  discussion  along  with  con¬ 
cluding  remarks  is  given  in  Section  6. 

2,  THE  REGISTER  TRANSFER  DESCRIPTION 

The  register  transfer  (RT)  description  is  a 
powerful,  and  hence,  popular  tool  for  describing 
digital  systems.  The  RT-language  introduced  here 
uses  the  commonly  adopted  syntax  notations.  Its 
design  is  xair.ly  intended  for  the  use  of  functional 
representation  and  functional  level  test  generation 
of  the  digital  system  under  test.  With  a  little 
modification,  it  can  be  extended  for  use  in  other 
related  applications  such  as  formal  machine  specifi¬ 
cations  in  computer-aided-design  (CAD). 

The  register-transfer  level  description  of  a 
digital  system  is  complete  with  two  distinct  de¬ 
scriptive  parts:  the  non-executable  part  and  the 
executable  part.  The  non-executable  part  consists 
of  a  set  of  declaration  statements.  There  are 
three  kinds  of  basic  declaration  statements  in  this 
part:  INPUT.  OUTPUT,  and  INTERNAL.  I  NT  IT  declares 
the  input  registers  of  the  system.  The  OUTPUT  and 
INTERNAL  oeclare  the  output  registers  and  the 
internal  registers  respectively.  Following  the 
nm-executable  part  is  the  executable  part.  This 
part  is  composed  of  register  transfer  statements 
with  syntax  to  be  discussed  in  the  next  few  para¬ 
graphs.  At  the  end  of  the  executable  part,  we  use 
an  "ENT"  tc  indicate  the  termination  of  the  overall 
RTL  cescription  of  the  system..  To  enable  easy 
reading  and  understanding  of  the  RT-statements, 
commentary  statements  enclosing  at  both  ends  with 
"i"  symbol  mav  be  inserted  anywhere  in  the  descrip¬ 
tion. 

A  number  of  operands  are  defined  here  repre¬ 
senting  arithmetic  operations,  logical  operations, 
shifts,  field  extractions,  and  bit  string  con¬ 
catenation.  The  domain  and  range  of  these  operands 
are  bit-strings.  Tbe  default  value  for  bit  string 
is  2 's-complem,ent  for  arithmetic  operations  and 
unsigned  for  logical  operations.  Both  decimal  and 
binary  integer  constants  cay  be  used  in  the  state¬ 
ments.  Each  operator  has  well-defined  rules  for  the 
resultant  bit-length  as  a  function  of  the  sizes  of 
input  operands.  In  addition,  some  operations  in¬ 
clude  implicit  sign-  crzero-extension  of  shorter 
operands  to  match  a  longer  one.  Figure  1  lists 
those  operators  defined  here  in  group  of  their 
natures.  Where,  ;  is  the  concatenation  operator 
and  ..  is  the  field  extraction  operator. 

Unary-operators::  *  unary-  NOT  INC  DEC 
adding-operators::  •  * 

logic-operators: :  ■  AND  OF  XOR  .  NOT 
relational-operators::  *  •  <> 

representat lonal 

operators::  *  sh t  '  shr  ■  f  .. 

Figure  1  Operators  defined  in  RT-statements 
A  typical  RT-statement  syntax  Is  giver  below: 
k:  (t.ciR.  -f(R. _ R.).~n  1  £  { ]  1 2 ; 

C  SI  SI 

where  k,  t,  c.  R^,  f,  Rs..,-*o,  and  --are  called  F.T- 
componer.ts.  The  ceanine  of  each  is  briefly  described 


below: 

k:  is  a  positive  intecer  representing  the  label  of 

an  RT-statecent . 

t:  is  a  one-bit  value  timing  flag. 

c:  is  the  condition  expression  with  relational 

operator  specifying  the  condition  for  performing 
the  register  transfer  operation. 

R , :  denotes  the  destination  register  of  the  RT- 
0 

statement . 

P.  .:  is  the  i-th  source  register, 
si 

f:  stands  for  an  ALU  operator  operating  on  the 

content(s)  of  source  register(s). 

-:  represents  the  transfer  of  the  result  of  RT- 

operation  to  the  destination  register. 

-n :  is  the  label  of  RT-statement  to  be  jumped  to 
after  current  RT-statement  is  finished  and  t 
and  c  are  true  if  present. 

The  operands  in  RT-expressions  may  be  regular 
registers  with  explicit  bit-length,  constant  regis¬ 
ters  with  or  without  explicit  bit-length,  or  macro 
registers  with  explicit  bit  length.  A  macro  regis¬ 
ter  is  a  group  of  registers  obtained  by  concate¬ 
nating  two  or  more  registers.  Note  that  memory 
reference  can  also  be  directly  expressed  in  an  RT- 
statement.  All  memory  references  are  represented 
by  a  memory  register.  The  above  typical  F.TL  state¬ 
ment  includes  the  following  types  of  RT-statements 
as  special  cases: 

.  Pure  transfer  statement:  k:  R,-R  ,-n 

C  S 

.  Data  operation  statement:  k:  R^-f  (F  ) 

.  Conditional  branch  statement:  k:  (c),-n 
.  Constant  transfer  statement:  k:  P^-’C.-T. 

Figure  2  shows  the  RT-description  for  a  hypothetical 
machine  called  SIMPLE-CALCULATOR.  After  the  first 
three  lines  of  declaration,  the  RT-description  of 
the  SIMPLE-CALCULATOR  starts  the  instruction  fetch 
cycle  followed  by  the  instruction  decoding  cycle 
and  then  the  Instruction  execution  cycle.  More 
discussion  of  the  defined  PT-language  car.  be  found 
in  16;. 

7SIMPLE  CALCULATOR’ 

^DECLARATION  PART' 

INPUT:  START (1),  DBS(l),  D3 f 6 ' ,  0?(3) 

OUTPUT:  AS(1) ,  A(83,  0(83,  F(D 

INTERNAL:  BS(1>,  B(6),  ECO.  SCO).  OS  ( 1 ,  SO) 

^PROGRAM  PARTD 
0:  5  —  START.  1 
1:  (S-0),  *  0 
2:  E  -  OP,  -  3 

I  INSTRUCTION  DECIDING  CHAIN'* 


5 . 

(E-001S3 

.  -  11  Laddt, 

4 : 

(E-010B) 

,  -  12  xsubtkac: 

5: 

(E-011B) 

,  -  13  7  MULT  I  ?L’ 

6: 

(E-100B) 

,  -  21  7LDAD  AT 

7: 

(E-101B) 

,  -  23  7L0AD  B' 

S: 

(E-110B) 

,  -  25  7LOA2‘  0' 

9: 

(E-111B) 

,  -  2*  xload  sc: 

10: 

S*0,  * 

o  ^otherwise: 

11: 

FSA* 

A+B.-1C 

12: 

F  <5  A  - 

A  -  B,  —  10 

13: 

AS  -  BS 

XOP,  08.  -  14 

14: 

A  -  0,  - 

■  15 

15: 

F  -  0,  - 

16 

16: 

(0(73-1) 

F  1  A  *  A  *  B, 

IT: 

f  ?  a  :• 

0  —  SHF  F  :  A  3 

18 


3 


18: 

sc 

-  SC-1,  -  19 

1 9  : 

is: 

0).  -  16 

20: 

c 

0,-0 

21: 

A 

DE,  -  22 

. 

AS 

-  DBS,  -  10 

23: 

B  - 

DB,  -  24 

21 : 

BS 

-DBS,  -  10 

25: 

Q  * 

DB,  -  26 

26: 

OS 

-DBS,  -  10 

2? : 

SC 

-  DB(1..3) , 

ENT 


Figure  2  An  example  of  RT-descriptior. 

3.  THE  RT-LEVEL  FAULT  MODEL  ANT'  FAITT  COLLAPSIN'-: 

Eased  on  the  typical  RTL  statement  giver,  in  the 
last  section,  nine  types  of  RT-level  faults  car 
be  derived.  The  functional  effect  of  these  faults 
can  be  analyzed.  The  results  are  described  in 
several  lemmas.  Based  or  these  lemmas,  analysis 
for  RT-level  fault  collapsing  is  conducted  and 
several  important  theorems  are  derived.  For  brevity 
only  the  major  lemmas  and  theorems  will  be  pre¬ 
sented  in  this  section.  Detailed  discussions  of 
the  ov  rail  development  car.  be  found  in  'bl. 

Definition  1.  After  a  digital  system  is  described 
by  a  set  of  RT-statemer.t s ,  the  overall  behavior  of 
the  system  is  detercir.ee  by  the  resultant  functions 
of  the  associated  RT-statecents .  Each  basic  com¬ 
ponent  in  an  RT-statement  is  called  a  register- 
transfer  (RD-coroonent . 

Definition  2.  A  digital  system  is  said  to  be  fault- 
free  if  it  operates  correctly  with  respect  to  its 
functional  specifications.  Otherwise,  it  is  said 
to  be  faulty  due  to  soce  register-transfer  level 
fault  occurring  in  the  basic  function  component 
of  the  system.  Faults  which  are  considered  in  the 
system  may  be  classified  according  to  their  fault 
effect  on  certain  RT-component  as  fault  tvpe.  The 
different  fault  values  under  each  occurrence  of 
fault  type  is  called  fault  case. 

Definition  3.  When  an  RT-component  F  becomes  faulty 
with  fault  type  F',  we  denote  it  by  F/F'. 

Based  on  the  typical  RTL  statement,  RT-level 
faults  can  be  classified  into  the  following  nine 
types. 

k/'k'  :  label  fault 

if t'  :  timing  fault 

c/c'  :  condition  fault 

.  (R)/(R)'  :  data  storage  fault 

’  :  data  transfer  fault 

R '■  R '  :  register  decoding  fault 

f'f  :  operator  decoding  fault 

.  (f)/(f)’  :  operator  execution  fault 

.  -n/-r.'  :  jump  fault 

The  following  lemmas  are  established: 

lemma  1 .  Fault  k/k'  means  that  the  label  of  an 
RT-statement  changes  from,  k  to  k'.  If  stuck-at- 
fault  is  assumed,  then  possible  faulty  situations 
are  : 

(i1  k ' ;  T  .  label  k  disappears. 

(ii)  k'Sk.^,  is  another  faulty  label  with  one 
bit  different  from  k  within  the  system's 
RT-address  space. 

fill)  k'?ks,  k:  is  a  non-existent  label  with  one 
bit  different  from  k  within  the  system's 
RT-address  space. 


where,  single-bit  stuck-at  fault  is  assumed  in  (ii) 
and  (ill)  . 

Proof : 

(1)  If  k/k'  occurs,  one  of  the  possible  faulty  cases 
is  chat  the  addressing  mechanism  for  k  is  totally- 
masked.  In  this  case,  no  k,  therefore,  will  be 
found  by  the  system's  execution  mechanism. 

(ii)  ( 1 i i 1  Suppose  A^  is  the  maximum  valid  address 

in  the  RT-address  space  of  current  digital  system 
and  B  is  the  bit  length  of  label  k.  When  k/k'?: 
occurs,  there  are  B  faulty  possibilities  k.,  1  <.  i 
L  B,  with  only  one-bit  different  from  the  correct 

bit  value  of  k.  For  those  k!  with  value  k!  ■  A  , 

i  is 

they  belong  to  the  fault  type  k'Ek^.  For  those  k^ 
with  the  value  k^  >  A^ ,  they  belong  to  the  fault 
type  k'  2  k- . 

To  save  space,  following  lemmas  are  stated 
without  proof.  The  detailed  proofs  can  be  found 
in  ’.61. 

Lerrcra  2 .  The  jump  section  of  an  RT-statemer.t  mav 
become  faulty.  We  use  the  notation  — n /— T. '  to  rep¬ 
resent  that  such  type  of  fault  occurs.  If  bridging 
fault  and  stuck-at-fault  are  assumed  in  the  jump 
section,  then  the  possible  faulty  situations  are: 

(1)  n'=c,  label  n  disappears. 

(ii)  n’=n  ,  tu,  is  another  faulty  label  with  one 

bit  different  from  n  within  the  system's 
RT-address  space. 

(iii)  n’=n-,  nc  is  a  non-existent  label  with  one 

bit  different  from  n  within  the  system's 
RT-address  space. 

(iv)  n'Hn  +  n  ,  both  n  and  are  simultaneously 

activated,  n  is  another  label  defined 
in  (ii).  3 

where,  single-bit  stuck-at-fault  is  assumed  in  (ii) 
and  (iii). 

Lemma  3 ■  The  timing  signal  of  an  RT-statement  may 
be  faulty  and  is  represented  by  t / t ' .  When  t / t ' 
occurs,  the  corresponding  RT-statement  will  not  be 
executed. 

Lemma  4 .  The  condition  control  mechanism  of  an  RT- 
statement  may  be  faulty  and  is  represented  by  c/c'. 
When  c/c'  occurs,  the  reverse  condition  instead  of 
the  ncrm3l  condition  is  true.  Under  this  case,  the 
corresponding  RT-statement  will  not  be  executed. 

Lemma  5 ■  The  content  of  a  register  may  be  faulty 
and  is  represented  by  (R)/(R)'.  We  assume  that 
stuck-at  and  bridging  faults  are  considered  in  this 
case  and  B«  R  is  the  bit  length  of  register  R. 

(i)  If  R  is  a  regular  register  which  car.  be  read 

or  written,  then  every  bit  in  R  may  either  be  stuck- 
at-0  or  stuck-at-1,  and  every  bit-pair  combination 
in  R  may  also  be  bridged  together.  The  total  num¬ 
ber  of  multiple  stuck-at-faults  is  3-1  and  the 
total  number  of  bridging  faults  is  B  x  (B-l)/2. 

(ii)  If  R  is  a  constant  register,  then  the  total 
number  of  fault  cases  is  B  by  considering  only 
single-bit  stuck-at  faults. 

Lemma  6.  The  content  in  a  register  transfer  path 
may  be  faulty  and  is  represented  by  If  stuck- 

at  fault  and  bridging  fault  are  considered,  then 
every  bit  in  the  path  may  be  stuck-at-0  or  stuck- 
at-1  and  every  bit-pair  combination  in  the  path  mav 
also  be  bridged  together.  The  total  number  of 
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multiple  stuck-at  faults  is  3B-1  and  the  total 
number  of  bridging  fault  is  B  x  (B-l)/3,  where  B 
is  the  bit-width  of  the  transfer  path. 

Lemma  7.  The  decoding  of  a  register  may  become 
faultv  and  is  represented  by  R/R'.  Assume  at  most 
one  register  will  be  selected  at  a  time,  then  the 
possible  fault  cases  are: 

(i)  R'i:,  no  register  is  chosen. 

(ii)  R'=E.,,  It.  is  another  register  with  similar 

register  characteristics  in  the  system. 

Lemma  8 .  The  selection  of  an  operator  in  the 
Arithmetic  Logic  Unit  (ALU)  may  be  erroneously  per¬ 
formed  and  is  denoted  by  f/f.  Assume  at  most  one 
operator  will  be  selected  at  a  time.  The  possible 
faulty  situations  are: 

(i)  r'Et,  no  operator  is  chosen. 

(ii)  f’Ef^,  fa  is  another  valid  ALL  operator  differ¬ 

ent  from  f. 

?mr.a  9.  The  execution  of  an  operator  in  ALL  may 
e  faulty  and  is  denoted  by  (f)/(f:'.  Due  to  the 
nature  of  the  faulty  effect  of  (f)/(f)’,  this  type 
cf  fault  is  difficult  for  modeling  in  register  trans¬ 
fer  level  and  may  only  be  attacked  at  the  circuit/ 
gate-level  or  implementation-dependent  level. 

Based  or.  the  above  Lemmas,  RT-level  fault 
collapsing  analysis  similar  to  that  of  gate-level 
stuck-at-faults  can  be  performed.  The  result  is 
described  in  the  following  theorems. 

Definition  4.  Two  RT-level  faults  Fj  and  F,  in  a 

digital  system  are  said  to  be  functionally  equi- 
V3~.  ent  if  anc  only  if  their  faulty  results  observed 
in  the  RT-level  description  of  the  syscem  are 
identical . 

Theorem_l.  In  an  RT-descr ipt ion ,  the  k/k'  type  of 
fault  is  coverec  by  (a  subset  of)  the  -*o  '—H '  type 
of  fault  by  Lemma  1  and  Lemma  2.  That  is: 

(i)  Both  ic/k’B:  and  k'k'Ek,  are  functionally 
equivalent  to  -r.  -n"«  -k'-r.  . 

(ill  k/k’Ek  is  functionally  equivalent  to  the 
combination  of  — n'T.'  *  -*kf— n;  and 
— n  — T.  *  -k  -'c-k^i. 

Proof :  Suppose  in  the  RT- fescrit t ion ,  there  are 
certain  FT-statene- ts  wit:  iurr  section  ^k,  and 


there  exists  an  FT-st 


h  statement 


au,  t  n  k  = :  cc  turs . 


1 1 , a  * ,  When  label  fault  k  ■  k  5:  occurs.  S.  are  net 
ifferted.  Wherea*-  tt.t  iabel  of  S  heco-es  t.  Wher¬ 
ever  ao.v  S  l-  S.  is  exe-utec.  toe  next  RT-state- 

rent  t‘  be  executed  is  f  in  fault-tree  case.  Nov, 
s 

sm:e  r.'ri  occurs,  brer-  is  n:  FT -  scat  em  ent  with 
lane!  k  an— .-re  S  if  virtual!',  n.  r-exister.t . 


W  «  ,  ,  S'"  t  xio  !  1  '< 


tc  a  n^r- ex i t er ?  ad-res*' 
result  ci  the  apreara-  s-e  c 
t s  he  the  fa.lt  c  f  : T. 


» r  rtr.e:  vc* res, 
V'r'l:  in  S.  turr.f 


R"-adire«s  spa-e. 
1  i  .  h  * .  When  k  ~ 


non-existent  FT  label  in  the 


are  net  affected. 


Whereas  toe  label  of  S  becomes  k  vt  1 :  h  is  r.on- 

K  C 

existent  in  valid  address  space  of  the  FT-descrip- 
tion.  Whenever  an.x  :  in  '.c.  is  executed,  the 

next  PT-stat e-ent  tc  he  execute- 


case.  Now,  since  k/k’mk.  occurs,  the  original  Sj. 

can  no  longer  be  addressed  within  the  valid  address 
space.  That  is,  every  in  {S^}  will  activate  a 

crap  to  a  non-existent  address  k.  In  other  words, 
the  result  of  the  appearance  of  k/k ' Hk,  in  turns 

out  to  be  functionally  equivalent  to  the  fault  of 
— k/-n.  in  each  of  ; S ^  ‘ - 

(ii)  Suppose  in  the  RT-description  there  are  other 
RT-stat  esents  *.  S  .  ■  with  jump  section  -*L,  and  there 
1 

exists  an  RT-statement  with  label  x.  When 

k/k'Sk^EJ.  occurs,  both  {S^cand  {S.:  are  not  affected. 

Whereas  the  label  of  S,  becomes  k  ;i.  Whenever  anv 

in  {s^.'  is  executed,  the  next  RT-statement  to 

be  executed  are  S.  and  S-  instead  of  S,  alone  in  the 
k  s  i 

fault-free  case.  And  any  in  {S..‘  now  will  acti¬ 
vate  a  trap  tc  a  r.cn-exister.t  address  k.  Ir.  other 
words,  the  result  of  the  appearance  of  k/fc'Ek^Ec 

in  turns  out  to  be  functionally  equivalent  to 

the  combined  faults  cf  •*k/‘*n-  in  each  S  of  (S.;  and 

S  i  l 

'  «— i/—  (J+k)  in  each  S.  of  {S.}.  The  notation 

't+k"  indicates  that  the  P.T-statement  with  label  i 
and  the  RT-statement  with  label  k  are  both  executed. 

Theorem  2.  Assume  the  internal  paths  among  recisters 
of  a  digital  system  are  all  parallel  links.  In  the 
RT-description  of  suer,  a  digital  system,  the  (R)/(R)' 
type  of  fault  defined  in  Lemma  5  is  covered  by  the 
*-/*-'  type  of  fault  defined  in  Lemma  6.  After  all 
*-/«•’  type  of  faults  are  tested,  the  (R)/(R;  '  type 
of  faults  are  automatically  tested. 

Proof :  If  a  register  is  redundant  in  the  system, 
then  either  its  behavior  is  transparent  tc  the 
system  specification  or  it  is  meaningless  tc  the 
correct  system  operation  (e.g.,  design  error).  For 
every  non-redundant  register  Rj  in  an  RT-description, 

there  always  exists  at  least  a  path  in.  the  system  to 
transfer  the  content  of  R^  out  tc  a  destination 

register,  say,  .  Whenever  the  content  of  is 

moved  out,  its  value  is  copied  onto  the  transfer 
path.  Therefore,  whatever  (F..)'  faults  will  be 
mapped  onto  its  associated  transfer  path  ir.  t'ne  RT- 
statement.  If  all  »/-'  fault  cases  or.  those  trans¬ 
fer  paths  connecting  all  register  \R_.  •  ir.  the  RT- 

descripticr.  are  tested,  then  all  fault  cases  of 

(R,)/(R,2'  are  automatically  tested, 
i  l 

Theorem  3.  Ir  an  PT-descript ion ,  fault  t/t*  is 
covered  b'-  the  combination  of  and  c  c’  types 

of  faults  by  Lemma  1,  3  and  That  is: 

(I)  When,  t  is  present  in  an  RT-statement  while  c  is 
absent,  t/t'  is  functionally  equivalent  tc  -n.'-r.'; 
n»l,  where  r.  is  the  label  of  this  RT-statement. 

(it’  When  both  t  and  c  are  present  ir.  an  PT-statement 
t/t'  Is  functionally  equivalent  to  c'c’. 

F roof :  (i)  By  the  definition  cf  t't',  when  t'  occurs, 
the  associated  RT-statement  will  not  be  executed. 

The  next  RT  statement  to  be  executed  is  hence  the 
PT-statement  next  tc  current  statement  ir.  the  RT- 
description.  This  is  exactly  what  haprens  when 
-*r.  ■—n.'rn^i  occurs. 


‘  c  c 

*  •  '  h. 


fault-free 
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(Hi  In  general  digital  systems,  the  timing  control 
signal  is  first  applied  to  accivate  the  associated 
RT-statement .  If  t'  occurs,  the  corresponding  RT- 
statement  will  not  be  activated.  When  t  is  active 
and  fault-free,  then  c  is  checked  if  present.  If 
c  is  true,  then  the  associated  RT-statement  will 
be  executed  otherwise  it  will  not.  However,  if 
c  c’  occurs,  the  associated  F.T-statenent  will  net 
be  executed  ever,  if  t  is  valid.  Hence,  t.'t'  and 
c  both  produce  the  same  faulty  behavior,  and  we 
mav  conclude  that  after  c/c'  is  tested,  the  t/t' 
type  of  fault  of  the  associated  RT-statement  is 
also  automatically  tested. 

Using  the  above  three  theorems  as  basis,  we 
establish  the  following  twe  theorems  for  test 
ger.erat  ior.. 

Tr.ecrer  ■».  In  an  RT-descr ipt ion ,  not  every  RT-level 
fault  type  defined  ir.  Lemma  1  through  Lemma  8  need 
be  considered  for  a  complete  test  set  under  the 
defined  RT-level  fault  model.  In  other  words,  the 
number  of  fault  types  car  be  reduced.  First,  the 
eight  noceied  RT-level  fault  types  can  be  collapsed 
to  five  by  Theorem  1  through  Theorem  3.  Second, 
only  or.e  of  those  RT-component s  which  functionally 
ccrresocnd  to  the  same  part  of  hardware  need  be 
considered  far  fault  cases. 

Proof :  (Tr.e  proof  is  lengthy  and  omitted  here.) 

The  ere-  f.  A  complete  test  set  for  the  fault  model 
stated  in  Lemma  1  through  Lemma  8  can  be  derived  if 
the  following  five  fault  types  ir.  every  RT-statem.er.t 
are  considered  with  each  fault  case  in  earn  fault 
tvoe  being  considered  or.lv  once: 

R'R',  f/f\  -r.  /— n  ’ ,  and  c/c' 

Procf :  The  proof  is  obvious  by  Theorem  a.  Suppose 
every  RT-statement  ir.  the  RT-descriptien  is  scanned 
serially  according  tc  a  predefined  order  derived 
from  the  RT-descriptior. .  If  any  of  the  above  five 
fault  types  Fj  occurs  ir  ar.  RT-statem.ent  and  the 
tests  for  Fj  are  net  yet  derived,  then  its  test  set 
will  be  generated  and  added  to  the  tests  obtained  so 
tar.  I:  F'  is  already  tested  somewhere  before 
Current  RT-statement,  then  it  is  skipped.  The  com¬ 
plete  test  set  car.  hence  be  computec  using  this 
procedure  repeatedly  until  every  RT-statement  is 
processed  in  this  way. 

d.  MAC-INI  swell  I C  EXECUTION  TECHNIQUE 

The  symbolic  execution  is  a  very  useful  soft¬ 
ware  engineering  technique  developed  originally  for 
program  analysis  including  test  data  generation 
/7, 8/  and  program  validation  19,101.  Due  to  the 
similarities  between,  software  and  hardware  imple¬ 
mentation,  most  key  principles  in  this  powerful 
technique  for  software  analysis  nay  also  be  used  for 
hardware  testing  and  verification  "11,121.  Su  and 
Ksieh  "131  first  pointed  out  the  general  idea  cf 
generating  tests  for  digital  svstecs  by  symbolically 
executing  the  fault-free  and  fault-injected  machines. 

Symbolic  execution  is  a  process  of  prograr 
execution  similar  tc  normal  execution,  except  that 
symbolic  values  of  variables  and  their  operation 
rules  are  included  in  addition  tc  normal  ones.  It 
involves  assigning  expression  instead  of  values  to 
variables  while  following  a  program  path.  An  ex¬ 
pression  represents  the  computation  that  would  have 
evolved  tc  cocpute  each  variable’s  value.  A 
symoolic  value  is  ar.  expression  of  constants  and 
variables  whose  contents  are  fixed  but  unknown  during 


the  symbolic  execution.  During  the  process  of  sym¬ 
bolic  execution,  everv  internal  variable  car.  alvavs 
be  described  as  ar.  expression  of  constants  and  sym¬ 
bolic  values  of  external  input  variables.  When  the 
symbolic  execution  proceeds,  a  binary  tree,  called 
symbolic  execution  tree  (SET)  which  shows  paths 
of  all  possible  symbolic  execution  flows  of  a  pro¬ 
gram.  will  be  developed.  If  a  particular  symbolic 
execution  path  is  followed  up  to  its  termination, 
a  set  cf  path  cc  restraints  and  that  path's  symbolic 
results  will  be  obtained.  Since  a  symbolic  exe¬ 
cution  takes  the  symbolic  values  of  all  its  ex¬ 
ternal  input  variables  as  input  data,  a  substantial 
number  of  actual  input  data  combinations  are  in¬ 
cluded  under  the  path  constraints  within  a  single 
symbolic  execution  of  the  program.  By  a  straight¬ 
forward  computation  the  desired  input  test  patterns 
which  distinguish,  fault-free  from,  faulty  operations 
mav  be  systematically  computed.  It  is  this  im¬ 
portant  feature  cf  symbolic  execution  that  makes 
it  a  powerful  tool  in  the  test  generation  algorithm 
under  development  in  this  research. 

Although  symbolic  execution  has  existed  for  a 
long  time  as  a  means  of  determining  the  semantics 
of  programs,  it,  however,  has  been  invariably  used 
mostly  for  programs  written  only  in  a  high-level 
language,  little  work  has  been  done  in  the  domain 
of  symbolic  execution  of  formal  machine  description. 
Oakley  .1-.  ,  however,  did  a  good  job  in  laying  the 
basic  theoretical  foundation  in  the  investigation 
of  this  topic.  Indeed,  there  are  two  major  dif¬ 
ferences  between  machine-level  symbolic  execution 
(HSEi  and  high-level-language  symbolic  execution 
(HSU:.  First,  the  major  goal  of  HSE  is  tc  confirm 
that  the  programmer  has  put  together  his  software 
proeram.  statements  in  a  correct  manner,  whereas 
HSE  is  mainly  concerned  with  the  correct  functioning 
of  the  hardware  primitives  themselves.  The  second 
major  difference  is  that  due  to  human  factors  and 
the  high  complexity-  of  software  design,  ESE  is  still 
very  difficult  and  restricted  to  use  in  many  appli¬ 
cations.  The  HSE.  or.  the  other  hand,  is  core 
amendable  tc  a  systematic  method  because  cf  the 
relative  simplicitv  of  the  definition  of  the  hard¬ 
ware  description  lancuace  (e.g.,  the  RT-  language 
defined  ir.  Section  2',  the  simpler  way  of  hardware 
description  and  so  on.  While  the  above  statements 
are  true,  HSE  still  has  its  own  problems.  The  basic 
issues  in  HSE  are:  equivalence  of  machine  symbolic 
execution  anc  actual  machine  execution,  variation  of 
bit-width  among  internal  register  paths,  the  repre¬ 
sentation  of  symbolic  context  and  path  constraints, 
the  problem  of  loops  and  termination  during  symbolic 
execution,  and  the  sine  1 i f icat ion  of  symbolic  ex¬ 
pressions.  A  detailed  discussion  of  all  c:  these 
and  their  solutions  can  be  found  ir.  [6, li.  anc  is 
omitted  here. 

The  symbolic  execution  system  developed  in 
this  research  is  composed  of  four  major  modules 
and  has  the  system  organizational  structure  as 
shown  in  Figure  3. 

Symbolic  Execution  Hcnitcr  (SEH)  I 

. _ _  -  '  .  i  _ _ _ 

Symbolic  i  Symbolic  ISymcciic 

'Execution  I  Expression  I  Inequality  ! 

•  Interpreter  (SE1)  j  Simplifier  (SES)j  j  Solver  (SIS) 

Figure  3  Organization  of  the  symbolic 
execution  svstem 
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In  Figure  3,  SE>!  Is  for  the  overall  control  of 
svrrbclic  execution  process.  SEI  interprets  the 
semantics  of  an  RT-stateiaent .  SES  performs  sym¬ 
bolic  expression  simtlificat icn.  SI?  Is  called 
only  when  the  symbolic  results  of  the  fault-free 
anc  fault-injected  paths  are  obtained. 

The  whole  symbolic  execution  system  consti¬ 
tutes  a  modular  part  of  the  overall  test  generation 
algorithm  to  be  discussed  in  the  next  section.  It 
acts  in  a  cocrdir.ated  vay  with  other  control 
mechanism  in  the  test  generation  algorithm.  From 
the  operational  standpoint,  the  internal  execution 
flow  of  the  whole  symbolic  execution  system,  is 
depicted  ir.  Figure  The  execution  loop  between 
SEI  and  SES  will  continue  until  the  last  RT-state- 
r.tnt  on  the  current  selected  path  is  executed.  At 
that  time,  SIS  will  be  activated  to  commence  exe- 

A  selected  path  ? 


The  symbolic  result  is  represented  internally 
as  a  directed  tree.  One  of  the  features 

of  tree  structure  is  the  easv  handlinc  of  its 
growth.  As  an  example,  consider  the  following 
tr.ree  R7-s caterer. ts  . 

5:  Rj  *  R,-?.,.  *  6 

t:  -  shr 

J  1 

r.  -  -  c 

After  statement  "  is  executed.  the  symbolic  value 
cf  ■-  will  be  shn'ir-  *  S K - "1  —  2  which  is  represented 

by  following  tree.  -p;  \ 


where,  Sr.,  ar.d  SF^  denote  the  primary  symbolic  value 
cf  input  register  R,  an:  R,  respective! v.  ‘R_  rep¬ 
resents  the  current  s\-mbolic  value  cf  F-. 


5.  THE  TEST  GENERATION  ALGORITHM 

In  this  secticn,  the  design  of  an  explicitly- 
defined  systematic  test  generation  algorithr  is 
presented.  The  overall  test  generation  algorithm 
is  developed  based  on  the  RT-level  fault  model 
discussed  in  Section  3  and  the  RT-level  symbolic 
execution  technique  described  in  Section  4.  There 
are  mainly  chree  design  considers t ions  behind  this 
functional  level  test  generation  algorithm: 

1'.  "Divide  and  conquer"  to  partition  a  big  problem 
into  smaller  ones. 

1 i  Modularity  and  Flexibility  for  steps  in  the 
algorithm,. 

3>  Algorithm  vs.  heuristics  for  becter  efficiency. 
Before  we  go  into  details  of  the  test  generation 
algorithm,  several  basic  assumptions  and  definitions 
of  common  terminologies  are  in  order. 

Definition  5.  A  functional  fault  is  redundant  if 
its  appearance  in  the  digital  system  does  r.ct  affect 
the  correct  functional  operations  specified  for  that 
digital  system.  Otherwise,  it  is  nor-redundar t ■ 

Definition  6.  A  functional  fault  is  itself  testable 
if  it  is  non-recundant  and  its  faulty  effect  can 
always  be  observed  at  the  output  port  of  the  system. 
Otherwise,  it  is  untestable. 

Definition  7.  A  functional  fault  is  detectable  by  a 
certain  test  set  if  it  is  observable  and  by  using 
proper  exercising  inputs,  its  faulty  effect  can  be 
observed  at  the  output  port  of  the  system.  Other¬ 
wise,  it  is  undetectable  to  that  test  set. 

Definition  8.  A  functional  fault  is  enumerable  if 
it  is  r.or.-redundar.t  and  car.  be  enumerated  within  a 
certain  upper  licit  based  on  reasonable  assumptions. 
Otherwise,  it  is  non- enumerable ■ 

Assumption  1.  Ir.  the  test  generation  algorithm  we 
map  the  physical  transfer  mechanism  such  as  a  bus 
described  in  the  RT-desrriptior.  into  a  logical  trans¬ 
fer  path.  This  is  because  test  engineers  working 
in  a  user  environment  mav  not  know  the  detailed  im¬ 
plementation  cf  the  mechanisms  for  transferrins  data 
between  functional  units,  or  how  they  are  shared  or 
multiplexed  among  different  RT-stacements .  Using 
the  logic  transfer  paths,  the  fault  model  for  the 
data  transfer  function,  is  independent  of  the  actual 
implementation  details  of  the  transfer  mechanisms. 

Assumption  2.  In  the  test  generation  algorithm, 
single  functional  fault  within  the  group  of  sensi¬ 
tized  RT-staremer.ts  is  assumed.  But,  we  allow  the 
presence  of  ar.v  number  of  faults  as  long  as  they 
don't  mask  the  one  currently  under  consideration. 

The  overall  test  generation  algorithm  is  con¬ 
ceptually  divided  into  three  parts:  pre-process, 
main-process  (the  S-aleorithcl ,  and  post-process. 

The  simplified  interaction  between  these  three  parts 
is  depicted  ir.  Figure  5. 

5.  Prep rocess 

The  pre-process  is  mainly  tc  perform  syntax 
checking  of  the  RT-descriptior.  of  the  svster-ur.der- 
test.  partition  the  whole  RT-description  into  a  set 
cf  ordered  function  submodules,  and  set  up  the  basic 
data  bases  needed  at  later  two  stages.  The  order 
o:  test  generation  among  the  RT-statements  in  over¬ 
all  RT-descrirtion  is  a  crucial  issue.  It  is  de¬ 
rived  using  the  function  submodules  in  the  RT- 
descriptior.  as  th--  basic  units  to  be  ordered.  A 


Source  R.'-description 
of  system-uncer-test 


Output  the 
report  of  test 
set 


Figure  5  Simplified  test  generation  flow 


function  submodule  is  a  loop  of  path  starting  from 
the  first  RT-statement  in  the  RT-description  and  has 
no  branching  path  at  the  last  node  of  the  path  right 
before  the  loop  is  formed.  The  logical  meaning  of 
function  submodule  in  a  general  digital  system  is 
just  like  the  "instruction"  in  a  processor. 

The  order  of  test  generation  of  testable  function 
submodules  is  set  as  follows: 

first:  pure-trar.sfer  vs.  non-pure  transfer 
second:  the  number  of  distinct  RT-statements 
third:  the  number  of  distinct  registers. 

A  function  submodule  with  neither  arithmatic  oper¬ 
ation  nor  logical  operations  is  called  a  pure-trans- 
fer  submodule.  The  start-small  principle  is  applied 
in  the  derivation  of  the  test  order  so  that  assump¬ 
tion  2  can  be  reasonably  justified. 

The  steps  performed  in  preprocess  stage  are  shown 
below: 

Step  1:  Perform  syntax  checking  of  RT-description 
representing  the  system-under-test  (SUT)  and  set  up 
associated  data  bases. 

Step  2:  Derive  all  function  submodules  within  the 

STrT 

Step  3:  Prepare  the  order  of  test  generation  among 
all  function  submodules  using  the  start-small  prin¬ 
ciple. 

Figure  6  shows  the  derived  order  of  test  generation 
among  the  eight  function  submodules  ir.  SIMPIE- 
CAlCVuATOR . 

5.2  The  S-algorlthn 

The  "S"  stands  for  "symbolic".  In  this  stage, 
the  RT-level  symbolic  execution  technique  is  in¬ 
tensively  employed  fcr  test  generation  of  each  fault 
modeled  in  the  RT-level  fault  model.  In  the  S-algo- 
rithm,  the  fault-free  description  of  current  function 
submodule  (FSj)  is  symbolically  executed  to  set  up 

a  symbolic  execution  subtree  (SET^)  which  near- 

minimally  covers  all  distinct  RT-statements  in  FS^. 

First,  test  Inputs  for  data  transfer  faults 
except  constant  transfers  (e.g.,  R^-l),  are  computed 

using  the  cransfer-test-f inding  heuristics  and  the 
symbolic  results  obtained  at  each  terminated  path. 
Faults  in  other  fault  types  are  enumerable  and  are 
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Figure  6  Function  submodules  in  the 
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injected  one  at  a  time  into  the  fault-free  RT- 
description.  For  each  fault  case  a,  the  symbolic 
execution  subtree  of  the  fault-injected  machine 

(SET^)  is  set  up  for  a  terminated  path.  The  inter¬ 
mediate  symbolic  values  along  the  fault-free  path 
are  saved  and  used  to  speed  up  the  generation  of 
such  a  path.  An  input  test  pattern  for  detecting 
this  fault  is  then  derived  by  comparing  the  symbolic 
results  and  path  constraints  of  the  fault-free  and 
fault-injected  machines.  Four  major  issues  must  be 
considered  in  the  S-algorithm:  how  to  find  the  near- 
minimal  covering  of  distinct  RT-statements  in  the 
function  submodules,  the  design  of  transfer-test¬ 
finding  heuristics  for  data  transfer  faults,  enumer¬ 
ation  and  identification  of  enumerable  faults,  and 
the  solving  of  symbolic  inequalities. 

Using  the  assertions  stated  in  Theorem  4  in 
Section  3,  only  all  distinct  RT-statements  in  each 
function  sub-module  FS,  need  be  considered.  There¬ 
fore,  not  every  symbolic  execution  path  in  FSi  need 
be  traversed  if  a  subset  of  symbolic  execution  paths 
which  near-minimally  covers  all  distinct  RT-state¬ 
ments  in  FSj  Can  be  found.  The  term  "near-minimal" 
is  used  in  the  sense  that  the  RT-statecent  covering 
is  formed  using  heuristics  rather  than  strict  complex 
algorithm.  The  data  transfer  faults  (■’-/-’)  is  re¬ 
garded  as  non-enumerable  faults.  The  heuristics 
for  transfer-test-finding  are  specially  designed 
for  the  efficient  generation  of  tests  for  such  kinds 
of  faults. 

Except  transfer  faults,  other  faults  need  to  be 
enumerated.  After  an  enumerated  fault  is  selected 
for  test  generation,  it  is  injected  into  the  cor¬ 
responding  RT-statement.  The  enumeration  process 
exhaustively  processes  each  enumerable  fault  under 
consideration.  Solving  symbolic  inequalities  is 
performed  after  the  symbolic  results  and  path  con¬ 
straints  of  the  fault-free  and  the  fault-injected 
machines  under  a  fault  a  are  obtained. 

The  steps  executed  by  the  S-algorithm  are  listed 
below: 

Step  4:  For  a  chosen  function  submodule  FS^  of  SUT, 
perform  machine  symbolic  execution  of  FS^s  RT-de¬ 
scription  to  set  up  a  symbolic  execution  subtree 
SET^  which  near-minimally  covers  all  distinct  RT- 
statements  in  FSi  b>'  bhe  path  set  {Pj j  ; . 


6 


Step  5:  Perform  heuristics  of  transfer-eesr-finding 
tc  find  test  patterns  for  data  transfer  faults  in  FS^. 

Ster  fe:  Choose  the  next  path  P,.  .  in  {P,,-. 

- - —  *j 

Step  7 :  Based  on  the  RT-leve’  fault  model  used, 
enumerate  and  inject  a  fault  a  which  has  not  beer, 
tested  along  P ,  . 

*  J 

Step  8:  Set  up  symbolic  execution  subtree  for  the 
fault-injected  machine.  Choose  one  terminated  path 

P^4  for  faulty  symbolic  results  anc  path  constraints. 

Step  9:  Derive  test  patterns  for  fault  a  by  com¬ 
paring  the  symbolic  results  and  path  constraints  of 

Fij  and  ?ly 

To  show  the  process  of  test  patterns  generation, 
let  us  consider  several  typical  illustrative  examples 
of  fault  cases. 

During  the  process  of  test  generaticr.  of  the 
simple-calculator,  the  RT-statement  11  :F4  A-A-S  ,-TO 
in  "addition"  submodule  (submodule  #1)  will  be  tested 
along  the  path:  0*1-*  2—  O-ll—lO-C . 

Based  on  the  conclusion  of  the  RT-level  fault 
collapsing  analysis  (Theorem  4.4  and  4.5),  only 
the  following  fault  types  need  be  considered  for 
this  statement: 

(1)  */*' 

(2)  P./S'  with  Reef,  A,  B} 

O)  -12/-12  ’ 

(4)  +/+' 

where, (2),  ( 3-1  ,  (4)  are  enumerable  fau’ts. 

Sow,  we  consider  cr.e  fault  case  out  of  each 
fault  type  for  illustration. 

(1)  -  In  performing  the  Transfer-Test-Finding 

operation  of  this  function  submodule,  the  transfer 
paths  of  statement  11  must  be  considered  are: 

-  transfer  paths  of  registers  A  and  B  to  Alt'  in¬ 
put  ports. 

-  ALT  output  port  t:  registers  F  and  A. 

Signal  stuck-at-fauits  and  bridging  faults  are  con¬ 
sidered  in*-/*'  fault  tvpe. 

@  -  Since  before  statement  11  is  executed,  the  sym¬ 
bolic  value  of  A  is  SA  and  B  is  SE,  to  test  path  of 
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oust  apply: 

SA 

SS 

11111111 

00000000 

1:11000: 

ooooopoo 

1100110- 

ocooooco 

1010101c 

0000000' 

0000000c 

00:00000 

:  path  of  E  tc  Al" 

input  pert,  we 

SA 

SB 

OOOOOOO: 

11:11:1: 

OOOOOOOC 

111:000: 

OOOOOOOL 

1:0:110: 

ooooooo: 

10:010:: 

OOOOOOOC 

00000000 

(2)-  Since  after  ALT  performed  the  addition,  the  re¬ 
sult  of  ALT  will  be  5A-SB.  C c  test  path  of  ALT  out¬ 
put  port  to  register  F  and  A,  we  must  apply: 

A-1000000C  B-1000000C 

in  addition  to  those  input  test  patterns  in  Q. 

(2;  R/P’  with  Rt-F,  A.  B--  The  fault  cases  under 
this  fault  tvpe  are: 

F'c'AS.  BS,  OS,  S  A'c-’s,  O'  B'c{A,  Q' 

Note  that  the  fault  cases  of  A'  and  B'  are  already 
considered  in  function  submodules  *4  and  A 5  and  need 
not  be  tested  again  here. 


Suppose  we  consider  F'*AS,  then  the  symbolic  results 
of  the  fault-free  machine  are: 

S-0  F-carry ( $A , SB)  AS-SAS  A-SA*SB,  where  S  is  a  sym¬ 
bolic  value  marker  and  the  symbolic  results  of  the 
fault-injected  machine  are: 

S^-0  F-j-SF  AS3-carrv  ($A,$E)  A^“  SA*SB,  where  a  is 
F7F'  -  F/AS  both  under  the  path  constraints:  S-l 
E-001. 

We  then  solve  the  set  of  algebraic  inequality 
equations : 

C 

carry  (SA,  SB)  4  SF  •  0 
0-SAS  4  carry  ($A,  SB) 


'S  (  S  - 

F/F,  * 


A  AS  4  AS^- 
(.A  4  Aa  *  : 

Therefore,  S-l  E-001  A-10000000  B*1 0000000  is  a 

feasible  test  pattern  for  this  fault  case. 

C3 >  -*12/-*12‘  -  The  fault  cases  under  this  fault  type 

are : 

12 'C  {13-001101  8-001000  28-011100 

14-001110  4-000100  44-101100- 

Suppose  we  consider  -*-12 '  -~13,  then  the  symbolic 
results  of  the  fault-free  machine  are:  S-0  F-carry 
(SA.SE)  A-SA-*SB  and  the  symbolic  results  of  the 
fault-injected  machine  are:  S--0  F-j-borrow 
(SA+SB- SB) -borrow) SA)-SF«2  A0-?A+SB-SB-SA,  both 
under  the  path  constraints:  S»1  E-001.  We  then 

solve  the  set  of  algebraic  inequalitv  equations: 

S  4  Sa  *  « 

0  4  carry  (SA,  SB) 

SA+SB  4  SA  which  turns  out  to  be 
SB  4  0. 

E-001  A-l 0000000  B-l 0000000  is  a 
feasible  test  pattern  for  this  fault  case. 

(4)  +/+'  -  The  fault  cases  under  this  fault  type 

are:  +'e{-,  XOR,  shr} 

Suppose  we  consider  +'  to  be  -,  then  the  symbolic 
results  of  the  fault-free  machine  are:  S-0  F-carry 
($A,$B)  A-SA+SB  and  the  symbolic  results  of  the 
fault-injected  machine  are:  S^-0  Fa-borrow($A,$B) 
A^-SA-SB,  where  a  is  *■!*■’  »  +/-  both  under  the 
constraints:  S»1  E-001. 

We  then  solve  the  set  c:  algebraic  inequality 
equations : 


i.  v  c 
{ 


F  S F* 

A  4  A_j 


Therefore,  S«1 


S  4  Sa 

F/F, 
,  A  4  A, 


-  carrv(SA.SB)  4  borrow  (SA,SB) 

—  $A*-S8  4  SA-S5  which  turns  out 

to  be  SB  4  0. 

Therefore.  S-l  E-001  A-10000000  B-10000000 

is  a  feasible  test  pattern  for  this  fault  case. 


5 . 3  Postprocess 

The  postprocess  stage  performs  the  following 
tasks : 

l'1  Perform  fault  screening  (elimination  of  covered 
faults  from  the  fault  list)  using  the  test  pattern 
just  derived  for  a  specific  fault  in  stage  two. 

2)  Repeat  the  S-algorithm  if  any  unprocessed  fault 
case  remains. 

3)  Perform  clean-up  for  hard-to-test  faults. 

4)  Prepare  the  test  generation  report. 

The  process  of  fault  screening  is  actually  a 
kind  of  simulation  which  simulates  the  test  pattern 
just  derived  in  the  S-algorithm  on  current  fault-free 
path.  Similar  fault  identification  and  numbering 
technique  used  in  the  S-algorithm  will  be  needed  here 
again. 

When  the  steps  in  the  S-algorithm  are  terminated, 
a  set  of  global  test  patterns  which  has  broad  fault 
coverage  for  the  entire  system-under-test  has  been 
generated.  Typically,  a  reasonable  number  of  faults 
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would  still  be  undetected.  The  difficult  task  now 
Is  to  generate  tests  to  "clean-up"  those  undetected 
faults.  Since  each  individual  fault  case  to  be  at¬ 
tacked  by  the  clean-up  operation  is  really  "hard-to- 
test”  (possibly  due  to  the  very  complex  hardware 
behavior  or  limitation  of  the  test  generation  policy 
currently  adopted),  the  combination  of  automatic 
test  generation  and  human  aids  are  both  included  in 
our  current  approach.  The  steps  performed  in  the 
postprocess  stage  are: 

Step  10:  If  no  test  pattern  is  obtained  in  Step  9, 
then  return  to  Step  8  and  try  another  Pv^ ;  other¬ 
wise  substitute  this  test  pattern  as  an  input  data 
into  P .  .  and  simulate  all  untested  faults  remaining 
on  P^  . J  Perform  possible  fault  cases  elimination 

along  Py. 


Step  11:  If  there  is  more  fault  cases  left  in  PJ  .  , 

- 1 -  ij 

then  return  to  Step  7. 

Step  12:  If  there  is  more  P ^  left  ir.  FS^({P1^!), 


then  return  tc  Step  6. 

Step  13:  If  there  is  more  FSi  left  ir.  the  SUT ,  then 
go  to  Step  4  and  repeat. 

Step  14:  Perform  possible  clean-up  operation  for 
"hard-to-test"  fault  cases  left  which  are  indicated 
in  the  housekeeping  tables. 

Step  15:  Prepare  test  generation  report  including 
test  patterns  obtained,  their  input  sequence  and 
other  useful  statistics. 


fe.  DISCUSSION  ANT  CONCH’S  IPS 

The  complexity  of  the  overall  test  generation 
algorithm  in  the  last  section  is  dominated  mainly 
by  the  S-algorithm.  A  preliminary  theoretic 
analysis  of  the  S-algcrlthm  shows  that  the  complexity 
of  the  S-algorithm  is  dependent  or.  the  total  number 
of  RT-statements  and  the  complexity  of  the  symbolic 
execution  system. 

The  S-algorithm  developed  has  several 
analogies  to  the  conventional  gate-level  D-algc- 
rithm.  It  has  the  following  features: 

1)  For  each  testable  RT-level  fault,  guarantee 
to  find  an  input  test  pattern  for  aetecting  that 
fault. 

2)  Systematically  find  ar.  input  test  pattern  as 
early  as  possible. 

3)  Identify  untestable  RT-level  faults. 

The  experimental  prototype  cf  the  overall  test 
generation  algorithm  is  being  implemented  or,  the 
IBM  370/168-compat ible  main  frame  computer  at  SVNY- 
Binghamton.  The  preliminary  experimental  results 
are  encouraging.  More  theoretical  studies  of 
complexity  analysis  of  the  S-algorithm  and  mere 
solid  experiments  on  several  typical  samples  are 
being  performed.  By  using  valuable  experience 
earned  in  software  testing  for  hardware  testing, 
this  technique  shows  a  promising  way  fer  future 
testing  problems  of  digital  LSI/VLSI  systems. 
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